Why does Isar build multiple configs in one OUTDIR?

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

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.

That way accidental reuse of any sort of build result is avoided. All
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.

And at the end there seems to be absolutely no reuse of build results,
which would be the only justification for such madness. All Isar does
is come up with long names to avoid such reuse.

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 recipes

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