From: Daniel Machon <dama@universal-robots.com>
To: Jan Kiszka <jan.kiszka@siemens.com>,
"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: RE: Custom recipe, multiple machines for same arch
Date: Fri, 5 Mar 2021 08:21:24 +0000 [thread overview]
Message-ID: <67d60dba3a5b4dcba6097b9f0e9f5fe1@universal-robots.com> (raw)
In-Reply-To: <2a8fcac4-d6c1-637b-a1e1-54a8e1dbabd4@siemens.com>
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
> -----Original Message-----
> From: Jan Kiszka <jan.kiszka@siemens.com>
> Sent: 3. marts 2021 13:05
> To: Daniel Machon <dama@universal-robots.com>; isar-
> users@googlegroups.com
> Subject: Re: Custom recipe, multiple machines for same arch
>
>
> CAUTION - EXTERNAL EMAIL: Do not open attachments or links unless you
> recognize the sender and the content is safe.
>
>
> On 03.03.21 12:37, Daniel Machon wrote:
> > Hi,
> >
> >
> >
> > Is there an elegant way to handle custom recipes, that are used in
> > multiple machines that target the same architecture.
> >
> > Currently when I try to execute a multi-machine build, it fails with:
> > */Detect multiple executions of ../*
> >
> > You can get around this by changing PN = /recipe-name/-${MACHINE} in
> > each custom recipe and IMAGE_INSTALL += /recipe-name/-${MACHINE}
> >
> > I am just wondering whether this is the best solution, or if there are
> > any alternatives?
> >
>
> Yes, you can share recipes across multiple configuration (multi-config).
> You will find examples of that in Isar itself and also in [1].
>
> But this can easily cause false-sharing problems. To detect those, we installed an
> instrumentation that reported such a case in your setup. It basically detects if
> there are variables evaluated by the recipe that vary across the builds for
> different multi-config targets.
>
> The next thing then is to understand what makes the recipes specific to the
> machines and then resolve that. One way is building the recipes machine-specific,
> this is what you described above. But maybe there is also a more elegant way in
> your case. This is hard to answer generally, though. You may try to compare the
> task signatures of the different runs via bitbake-diffsigs which should visualize the
> varying vars.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
[Daniel Machon]
I will stick with the machine-specific recipes for now - this seems to be a reasonable solution in this case.
Thank you 😊
[-- Attachment #2: Type: text/html, Size: 2963 bytes --]
prev parent reply other threads:[~2021-03-05 8:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 11:37 Daniel Machon
2021-03-03 12:04 ` Jan Kiszka
2021-03-03 12:05 ` Jan Kiszka
2021-03-05 8:21 ` Daniel Machon [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=67d60dba3a5b4dcba6097b9f0e9f5fe1@universal-robots.com \
--to=dama@universal-robots.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.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