[OE-core] Question regarding project organization with OE

[Logan Buchy]

Hi,

It's my first time posting here, I hope I have the right mailing list!

I've been looking into OE in the last few days as a candidate to replace
the ageing build scripts in a project I am involved with.  I've been really
impressed with OE's feature list - it ticks off a lot of boxes for our
requirements.

I am still working out some of the workflows though before we go ahead and
make the switch, I was hoping someone could help me out.

The project I am working on consists of several embedded targets.  All
targets currently run on the same system-on-chip and are built with the
same toolchain, though this will note be the case in the near future. The
majority of the project exists as a monolithic application that is built
with different DEFINEs in order to customize the application's behaviour.
Each target also has a unique rootfs layout (different init scripts mostly).

For the sake of clarity, lets call this application 'Foo', and two targets
'alpha' and 'beta'.

I am trying to figure out the best was to setup recipes in order to
maintain this structure.

I'm thinking that managing the targets is best left to image-recipes in a
separate layer.  Essentially adding:
* recipes-core/images/target-alpha.bb
* recipes-core/images/target-beta.bb

Managing the 'Foo' application is currently done with a regular package
recipe:
* recipes-core/Foo/foo.bb

However, I am not sure if the image recipes can dictate how to build Foo,
the dependent recipe.  Is this possible? Is there an alternative workflow?

Would it be better if 'targets' were managed as separate distros instead?
Currently some targets use different kernel versions than others, and all
targets use different kernel configs.  I haven't yet figured out if this is
possible to specify from within an image recipe.

Any help is appreciated!

Thanks,
Logan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20151009/64dfdc51/attachment-0002.html>