[yocto] Slightly varying builds

[Colin Helliwell]

> On 02 November 2017 at 16:29 Alexander Kanavin <alexander.kanavin at 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?