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

[Alexander Smirnov <asmirnov@ilbers.de>]

On 08/10/2017 03:17 PM, Henning Schild wrote:
> 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.

Product is what you sell in the market. From technical point of view, 
product can be described as a set of 3 parts: hardware, base system, 
application layer. In typical cases, you maintain the application layer 
only, the other things are provided by suppliers (internal or external). 
Releasing new version of your application layer forces you to provide 
software update for whole product-line officially supported.

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

Why each Isar user should wrap such scripts for each project, when this 
can be a part of basic functionality? Does this really make Isar less 
complicated?

I'd agree with your concern in context, that this design can be overhead 
for case where we have *single* machine and *single* distro version. But 
initial Isar idea was to support products with matrix of configurations.

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

-- 
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 Munich
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov