Why does Isar build multiple configs in one OUTDIR?
36 views
Skip to first unread message
Henning Schild
Aug 10, 2017, 3:09:03 AM8/10/17
to isar-...@googlegroups.com, Alexander Smirnov, KISZKA, JAN, Baurzhan Ismagulov
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
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
Henning Schild
Aug 10, 2017, 8:15:59 AM8/10/17
to Alexander Smirnov, isar-...@googlegroups.com, KISZKA, JAN, Baurzhan Ismagulov
Am Thu, 10 Aug 2017 14:22:14 +0300
schrieb Alexander Smirnov <asmi...@ilbers.de>:
> Henning Schild <henning...@siemens.com> 10 августа 2017 г.
> 10:09:06 написал:
> works, including Yocto and OE. Please avoid "labels" in your comments.
> 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.
> 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.
> same approach.
> > 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
schrieb Alexander Smirnov <asmi...@ilbers.de>:
> Henning Schild <henning...@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
> > 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.
>
> 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
> >
> > That way accidental reuse of any sort of build result is avoided.
>
> 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.
>
> 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
> >
> > And at the end there seems to be absolutely no reuse of build
> > results,
>
> 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
> > which would be the only justification for such madness. All Isar
> > does is come up with long names to avoid such reuse.
>
> 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.
> >
> > 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
>
> 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
Baurzhan Ismagulov
Aug 10, 2017, 9:10:01 AM8/10/17
to isar-...@googlegroups.com
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.
> > > 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.
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.
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? What for? Isar *is*
the single-stop glue.
With kind regards,
Baurzhan.
Alexander Smirnov
Aug 10, 2017, 9:31:56 AM8/10/17
to Henning Schild, isar-...@googlegroups.com
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.
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
Alexander Smirnov
Aug 10, 2017, 9:31:57 AM8/10/17
to Henning Schild, isar-...@googlegroups.com, KISZKA, JAN, Baurzhan Ismagulov
> 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.
>
> 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.
>
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)
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.
> 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.
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.
> 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.
>
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
> 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
machine and distro. One of the initial Isar requirement was to have
possibility to support whole product, where product can have different
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.
etc... bring unnecessary effort and complexity to whole product
And as bigger product machine/distro matrix, as much more complicated to
support it.
Alex
support it.
Henning Schild
Aug 10, 2017, 9:50:42 AM8/10/17
to Baurzhan Ismagulov, isar-...@googlegroups.com
Am Thu, 10 Aug 2017 15:09:51 +0200
schrieb Baurzhan Ismagulov <i...@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.
>
schrieb Baurzhan Ismagulov <i...@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.
> 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.
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?
> What for?
Simplicity, Elegance, Maintainability, Modularity ... ty
> Isar *is* the single-stop glue.
Henning
> With kind regards,
> Baurzhan.
>
Baurzhan Ismagulov
Aug 10, 2017, 10:25:13 AM8/10/17
to isar-...@googlegroups.com
On Thu, Aug 10, 2017 at 03:52:37PM +0200, Henning Schild wrote:
> > 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.
ICH Plant Edition contains multiple cards that are armhf, use wheezy but have
> > 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.
different user-space applications. They share the same buildchroot.
> > 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.
The fact is, the products are already layered and split in different git repos.
Apart from the fact that Isar predates kas and solves the problem well: I'd use
kas for cloning disparate repos (like the repo tool in Android), not for build
dir management.
> > What for?
>
> Simplicity, Elegance, Maintainability, Modularity ... ty
in these regards.
If you need only one arch + suite combination, you may still use local.conf
without multiconfig.
And if you like, you may still layout your product to your taste and use your
preferred solution with stock Isar. What is exactly the problem you are trying
to address? Multiconfig doesn't take anything away from you. Artifact reuse is
in place within the same arch + suite.
With kind regards,
Baurzhan.
Jan Kiszka
Aug 10, 2017, 12:37:24 PM8/10/17
to isar-...@googlegroups.com
On 2017-08-10 10:25, Baurzhan Ismagulov wrote:
>>> 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.
>
> Maybe? Please specify how you suggest to build images for ICH WE and PE.
>
> The fact is, the products are already layered and split in different git repos.
> Apart from the fact that Isar predates kas and solves the problem well: I'd use
> kas for cloning disparate repos (like the repo tool in Android), not for build
> dir management.
kas manages config dependencies that are under the same release regime
>>> 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.
>
> Maybe? Please specify how you suggest to build images for ICH WE and PE.
>
> The fact is, the products are already layered and split in different git repos.
> Apart from the fact that Isar predates kas and solves the problem well: I'd use
> kas for cloning disparate repos (like the repo tool in Android), not for build
> dir management.
in a single file. It also provides a clean, archiveable build
environment, which is even more important with OE.
If your production generates multiple variants from a single release,
there is surely a value in exploiting the new multiconfig feature of
bitbake. It's an optimization that can save a hand full of lines in your
CI script and likely quite a bit cycles of your CI server. I see it as
an added value. But as Isar is already wrapped around it, no longer
works without it (because that would mean duplicate maintenance), we
have to make sure to support it, including a better support in kas.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Henning Schild
Aug 11, 2017, 4:14:13 AM8/11/17
to Baurzhan Ismagulov, isar-...@googlegroups.com
Am Thu, 10 Aug 2017 16:25:02 +0200
schrieb Baurzhan Ismagulov <i...@radix50.net>:
> On Thu, Aug 10, 2017 at 03:52:37PM +0200, Henning Schild wrote:
> > > 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.
>
> ICH Plant Edition contains multiple cards that are armhf, use wheezy
> but have different user-space applications. They share the same
> buildchroot.
Ok that is the example i asked about initially. Thanks!
Henning
schrieb Baurzhan Ismagulov <i...@radix50.net>:
> On Thu, Aug 10, 2017 at 03:52:37PM +0200, Henning Schild wrote:
> > > 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.
>
> ICH Plant Edition contains multiple cards that are armhf, use wheezy
> but have different user-space applications. They share the same
> buildchroot.
Henning
Baurzhan Ismagulov
Aug 11, 2017, 2:20:34 PM8/11/17
to isar-...@googlegroups.com
On Thu, Aug 10, 2017 at 12:37:01PM -0400, Jan Kiszka wrote:
> kas manages config dependencies that are under the same release regime
> in a single file. It also provides a clean, archiveable build
> environment, which is even more important with OE.
>
> If your production generates multiple variants from a single release,
> there is surely a value in exploiting the new multiconfig feature of
> bitbake. It's an optimization that can save a hand full of lines in your
> CI script and likely quite a bit cycles of your CI server. I see it as
> an added value. But as Isar is already wrapped around it, no longer
> works without it (because that would mean duplicate maintenance), we
> have to make sure to support it, including a better support in kas.
Just to ensure we are talking about the same thing: BitBake's multiconfig
> kas manages config dependencies that are under the same release regime
> in a single file. It also provides a clean, archiveable build
> environment, which is even more important with OE.
>
> If your production generates multiple variants from a single release,
> there is surely a value in exploiting the new multiconfig feature of
> bitbake. It's an optimization that can save a hand full of lines in your
> CI script and likely quite a bit cycles of your CI server. I see it as
> an added value. But as Isar is already wrapped around it, no longer
> works without it (because that would mean duplicate maintenance), we
> have to make sure to support it, including a better support in kas.
feature is a means of building for multiple MACHINE + DISTRO configurations in
a single run without having to deal with local.conf in between. Multiconfig and
local.conf are completely equivalent and mutually interchangeable. BitBake and
Isar support either without requiring the other, or both. In the same build
dir, one can use local.conf for one bitbake run and multiconfig for another;
the results are the same. We refer to multiconfig in the user manual to avoid
lengthier textual description of editing local.conf.
I agree with both of your points:
* Combining two non-multiconfig builds via external tools would add maintenance
overhead, and
* kas's goal is CM of disparate entities under the same release regime rather
than dealing with build issues.
With kind regards,
Baurzhan.
Jan Kiszka
Aug 19, 2017, 9:53:57 AM8/19/17
to isar-...@googlegroups.com
On 2017-08-11 14:20, Baurzhan Ismagulov wrote:
> On Thu, Aug 10, 2017 at 12:37:01PM -0400, Jan Kiszka wrote:
>> kas manages config dependencies that are under the same release regime
>> in a single file. It also provides a clean, archiveable build
>> environment, which is even more important with OE.
>>
>> If your production generates multiple variants from a single release,
>> there is surely a value in exploiting the new multiconfig feature of
>> bitbake. It's an optimization that can save a hand full of lines in your
>> CI script and likely quite a bit cycles of your CI server. I see it as
>> an added value. But as Isar is already wrapped around it, no longer
>> works without it (because that would mean duplicate maintenance), we
>> have to make sure to support it, including a better support in kas.
>
> Just to ensure we are talking about the same thing: BitBake's multiconfig
> feature is a means of building for multiple MACHINE + DISTRO configurations in
> a single run without having to deal with local.conf in between. Multiconfig and
> local.conf are completely equivalent and mutually interchangeable. BitBake and
> Isar support either without requiring the other, or both. In the same build
Theoretically, Isar could still build without multiconfig. But
> On Thu, Aug 10, 2017 at 12:37:01PM -0400, Jan Kiszka wrote:
>> kas manages config dependencies that are under the same release regime
>> in a single file. It also provides a clean, archiveable build
>> environment, which is even more important with OE.
>>
>> If your production generates multiple variants from a single release,
>> there is surely a value in exploiting the new multiconfig feature of
>> bitbake. It's an optimization that can save a hand full of lines in your
>> CI script and likely quite a bit cycles of your CI server. I see it as
>> an added value. But as Isar is already wrapped around it, no longer
>> works without it (because that would mean duplicate maintenance), we
>> have to make sure to support it, including a better support in kas.
>
> Just to ensure we are talking about the same thing: BitBake's multiconfig
> feature is a means of building for multiple MACHINE + DISTRO configurations in
> a single run without having to deal with local.conf in between. Multiconfig and
> local.conf are completely equivalent and mutually interchangeable. BitBake and
> Isar support either without requiring the other, or both. In the same build
practically, more and more information is now only in
meta-isar/conf/multiconfig, and one would has to copy that out into an
own local.conf (or a kas config).
But focusing on one method is fine, we should just avoid confusions
regarding the other.
Baurzhan Ismagulov
Aug 21, 2017, 8:16:21 PM8/21/17
to isar-...@googlegroups.com
On Sat, Aug 19, 2017 at 09:53:54AM -0400, Jan Kiszka wrote:
> Theoretically, Isar could still build without multiconfig. But
> practically, more and more information is now only in
> meta-isar/conf/multiconfig, and one would has to copy that out into an
> own local.conf (or a kas config).
Good catch, thanks. Indeed, building with the default local.conf produces a
> Theoretically, Isar could still build without multiconfig. But
> practically, more and more information is now only in
> meta-isar/conf/multiconfig, and one would has to copy that out into an
> own local.conf (or a kas config).
working image, albeit the kernel / initrd is not extracted.
https://github.com/ilbers/isar/issues/29
> But focusing on one method is fine, we should just avoid confusions
> regarding the other.
it. Besides, local.conf would save people with one config the cumbersome
multiconfig syntax.
I think keeping local.conf working shouldn't cost too much effort -- in the
worst case, the vars added to multiconfig should also be added to local.conf.
Maybe we manage to come up with some standard customization file location
without having to repeat ourselves.
With kind regards,
Baurzhan.
Reply all
Reply to author
Forward
0 new messages