From: Henning Schild <henning.schild@siemens.com>
To: Baurzhan Ismagulov <ibr@radix50.net>
Cc: <isar-users@googlegroups.com>
Subject: Re: Why does Isar build multiple configs in one OUTDIR?
Date: Fri, 11 Aug 2017 10:16:09 +0200 [thread overview]
Message-ID: <20170811101609.7eb7a8ce@md1em3qc> (raw)
In-Reply-To: <20170810142501.GA4053@yssyq.radix50.net>
Am Thu, 10 Aug 2017 16:25:02 +0200
schrieb Baurzhan Ismagulov <ibr@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
>
> > > 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.
>
>
> > > What for?
> >
> > Simplicity, Elegance, Maintainability, Modularity ... ty
>
> After you specify your image building solution, please show how yours
> is better 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.
>
prev parent reply other threads:[~2017-08-11 8:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-10 7:10 Henning Schild
2017-08-10 11:22 ` Alexander Smirnov
2017-08-10 12:17 ` Henning Schild
2017-08-10 12:46 ` Alexander Smirnov
2017-08-10 13:09 ` Baurzhan Ismagulov
2017-08-10 13:52 ` Henning Schild
2017-08-10 14:25 ` Baurzhan Ismagulov
2017-08-10 16:37 ` Jan Kiszka
2017-08-11 18:20 ` Baurzhan Ismagulov
2017-08-19 13:53 ` Jan Kiszka
2017-08-22 0:16 ` Baurzhan Ismagulov
2017-08-11 8:16 ` Henning Schild [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170811101609.7eb7a8ce@md1em3qc \
--to=henning.schild@siemens.com \
--cc=ibr@radix50.net \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox