From: "Eric Bénard" <eric@eukrea.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: SRC_URI computing order
Date: Fri, 1 Nov 2013 16:36:11 +0100 [thread overview]
Message-ID: <20131101163611.37a8c084@e6520eb> (raw)
In-Reply-To: <20131028151004.34b2af21@e6520eb>
Hi,
Le Mon, 28 Oct 2013 15:10:04 +0100,
Eric Bénard <eric@eukrea.com> a écrit :
> I saw your patch fixing FILESPATH's and Kergoth's one fixing
> PACKAGECONFIG processing order and I think I'm also facing an order
> problem when SRC_URI is computed.
>
> So when building SRC_URI when two layers have bbappend which apply
> patches : the SRC_URI seems to be built using an order I fail to
> understand somewhere instead of priority or the overrides' order.
>
> The use case is a System on Module and its custom motherboard :
> - meta-fsl-arm :
> * linux-imx_xyz.bb :
> SRC_URI = "patchgeneric1 ..."
>
> - meta-som-support :
> * conf/machine/mysom.conf
>
> * linux-imx_xyz.bbappend :
> SRC_URI_append_mysom = "patchsom1 patchsom2 ..."
>
> - meta-custommotherboard (SOM + Cunstom Motherboard) :
> * conf/machine/myproduct.conf
> MACHINEOVERRIDES_prepend = "mysom:"
> include conf/machine/mysom.conf
>
> * linux-imx_xyz.bbappend :
> SRC_URI_append_myproduct = "patchproduct1 patchproduct2 ..."
>
> in the end I get :
> SRC_URI = "patchgeneric1 ... patchsoc1 ... patchproduct1 ...
> patchsom1 ..."
>
> and of course as patchproduct* are supposed to apply on top of
> patchsoc* the patch fail to apply.
>
> I didn't found a way to build SRC_URI in the order I would like (I
> tested : changing MACHINEOVERRIDES 's order, changing layers' priority,
> changing machine's name to see if that was an alphabetical order ...).
>
> In the end the only thing which worked was to add an (empty by default)
> variable in som's SRC_URI and filling this variables from the
> custommotherboard's bbappend.
>
> Is the behaviour I'm seeing expected or is there something wrong in my
> setup ?
>
do you need more details concerning this problem ?
Thanks
Eric
next prev parent reply other threads:[~2013-11-01 15:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 22:42 [PATCH] utils.bbclass: Fix override ordering for FILESPATH Richard Purdie
2013-10-28 14:10 ` SRC_URI computing order Eric Bénard
2013-10-29 3:45 ` Khem Raj
2013-10-29 7:28 ` Eric Bénard
2013-10-30 15:15 ` Richard Purdie
2013-11-02 8:47 ` Eric Bénard
2013-11-03 22:16 ` Andrea Adami
2013-11-03 23:10 ` Richard Purdie
2013-11-04 22:13 ` Andrea Adami
2013-11-06 8:45 ` Andrea Adami
2013-11-07 23:20 ` Richard Purdie
2013-11-08 11:55 ` Otavio Salvador
2013-11-04 8:33 ` Eric Bénard
2013-11-01 15:36 ` Eric Bénard [this message]
2013-11-01 18:16 ` Richard Purdie
2013-11-02 8:45 ` Eric Bénard
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=20131101163611.37a8c084@e6520eb \
--to=eric@eukrea.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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