public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      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