> On 02 November 2017 at 16:29 Alexander Kanavin
> <alexander.kana...@linux.intel.com> wrote:
>
> On 11/02/2017 06:26 PM, Colin Helliwell wrote:
>
> > Following on from this, I'm trying to be able to build my two versions of
> > u-boot, in the *same* build directory.
> > I'm not sure if this is possible, but I figured it might be: since u-boot
> > doesn't get put into the rootfs (?), I would ideally be able to build both
> > and just pull down from tmp/deploy/images/.... the image that I want to
> > program into a particular unit.
> > I've pushed common stuff into .inc file(s), and have two recipes which set
> > different 'PROVIDES' values.
> > However, even after a cleanall on both recipes, bitbaking the second one
> > throws an error "The recipe u-boot-mymachine-dev is trying to install files
> > into a shared area when those files already exist".
>
> Can you share exactly how the two recipes differ?
>
Very little!
One is:
DESCRIPTION = "Das U-Boot for W2 [for development]"
DEP_IMG = "u-boot-dev"
PROVIDES = "u-boot-w2-dev"
require u-boot-w2_1.inc
The other is:
DESCRIPTION = "Das U-Boot for W2"
DEP_IMG = "u-boot-prodn"
PROVIDES = "u-boot-w2"
require u-boot-w2_1.inc
u-boot-w2_1.inc has the standard kind of recipe stuff. For creating env files,
and files to be used for later signing, it has some _append steps, so I'm
aiming to use 'DEP_IMG' to create the various files with different prefixes for
the two variants.
Strangely though, an 'echo ${DEP_IMG}' is outputting the same value
("u-boot-prodn") from both recipes, even after a cleanall on both. Possibly
some state info being pulled in somewhere?
> It seems that you do need to have two different build directories that
> differ in what MACHINE is set to. And that would configure u-boot
> accordingly.
>
I *do* realise I'm trying to do something a bit unusual!
All I want between the two variants is to disable some functionality - the
'machine' is identical. I was going to patch one build to take the
functionality out (for 'production'), but create my own specific environment
for the system anyway. So I wonder if a cleaner/easier (aka working...!)
approach would be to instead patch my own custom envar into the source, and
then I could instead create two different env files for the two variants?
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
