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

[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)

> 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.
>
> 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. 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. 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.

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