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

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

Am Thu, 10 Aug 2017 14:22:14 +0300
schrieb Alexander Smirnov <asmirnov@ilbers.de>:

> Henning Schild <henning.schild@siemens.com> 10 августа 2017 г.
> 10:09:06 написал:
> 
> > Hey,
> >
> > at first i did not get the whole "extra-stamp" and ultra-deep
> > directory structure /DISTRO/ARCH/... But now i got it, Isar
> > actually builds multiple configs in a shared output directory. And
> > in order to do so it has to make sure that every single file does
> > not create a name collision. Coming up with extra-stamps and other
> > funny stuff.  
> 
> It's not a "funny" stuff, it's how almost all the build systems
> works, including Yocto and OE. Please avoid "labels" in your comments.
> 
> >
> > That way accidental reuse of any sort of build result is avoided.  
> 
> That's not true. Build for two machines with similar architecture and 
> distro will reuse buildchroot and build results (if there are no
> machine specific stuff)

Is that the point i covered in the last section?

> > recipes inherit that complication and have to play along i.e. when
> > creating temporary files. Avoiding clashes is a very hard job to get
> > right throughout the whole system.  
> 
> Bitbake already provides *dedicated* way to do this, so we just use
> it.
> 
> >
> > And at the end there seems to be absolutely no reuse of build
> > results,  
> 
> Again, that's not true. You probably speak about current
> implementation, where we have sample machines to demontrate PoC. But
> Isar in general is a tool to build your product and main design
> requirements have come from real projects.
> 
> > which would be the only justification for such madness. All Isar
> > does is come up with long names to avoid such reuse.  
> 
> That's the way how bitbake works. As I said, Yocto and OE uses the
> same approach.
> 
> >
> > If you are building a kernel for two targets you use two O=, same is
> > true for cmake-projects and many other build systems out there.
> >
> > 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.

> > IMHO what should happen is:
> > - you clone your Isar once
> > - you clone your multiple target layers to _different_ dirs
> > - you run many (parallel) bitbakes in these dirs
> > - you _never_ build two targets in the same tree
> > - we drop all the complexity and do not force it down into
> >   end-users  
> 
> I suppose that you are speaking about single use where you have
> specified machine and distro. One of the initial Isar requirement was
> to have possibility to support whole product, where product can have
> different platform and different base-system version.

What is a "product"? I would say the Iphone is a product and you would
have 7 configs for its respective versions. I can see how you would
want to build those 7 in one tree. What you are suggesting is the whole
"product line" of Apple in one "product", from the smalles ipod to the
workstations.

> To release this
> product, you should build everything at once. Fetching various
> directories, setup them etc... bring unnecessary effort and
> complexity to whole product maintenance.

Wrap the building with a script, i.e. have a look at kas.

> Product is a single unit,
> that can't be split into the layers. And as bigger product
> machine/distro matrix, as much more complicated to support it.

How can one atomic thing have multiple architechtures, i do not get
that point at all! Is your product a whole building or airplain? Even
if it was it needs to be modular ...

Henning

> Alex
> 
> >
> > I think there is the one use-case where you build two very same
> > images with the same ARCH DISTRO etc. and actually want to reuse.
> > That probably already works out of the box and if it does not,
> > coming up with long stamps and directory names that carry the
> > shared attributes does not help at all.
> >
> > Henning  
> 
>