Re: Why does Isar build multiple configs in one OUTDIR?

[Henning Schild <henning.schild@siemens.com>]

Am Thu, 10 Aug 2017 15:09:51 +0200
schrieb Baurzhan Ismagulov <ibr@radix50.net>:

> On Thu, Aug 10, 2017 at 02:17:54PM +0200, Henning Schild wrote:
> > > > The only reuse of a build step i see at the moment is the
> > > > git-clone of Isar itself. Where are the gains that justify the
> > > > complexity? If there is a good reason, that i did understand
> > > > yet, please answer to this point and you can stop reading
> > > > here.  
> > 
> > Please answer this key question, with examples.  
> 
> Alex did.

Well I did not understand it. And i still do not.

> Industry Control Hub Workshop Edition is armhf and uses jessie.
> Industry Control Hub Plant Edition is armhf and uses wheezy.
> They share the same user-space application.

So two complete rootfs s that share one application? And they probably
only share the source and recipe to build it.
I still do not see where these two share any (intermediate) build
results, sorry.

> The application is updated.
> Both models are released.
> You build them from the same build dir.

?

> This comes from real life and this has been the key requirement on
> Isar from the very beginning. The customer wants to build all
> artifacts with the same release cycle in one step.
> 
> If we returned to the pre-multiconfig way of having separate build
> dirs, automating building all products in the repo would require
> gluing those two steps together. How? Shell with sed patching of
> local.conf? 

Bitbake Layering. Maybe combined with git submodules or kas.

> What for?

Simplicity, Elegance, Maintainability, Modularity ... ty

> Isar *is* the single-stop glue.

Ok. Understood but not convinced.

Henning

> With kind regards,
> Baurzhan.
>