All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Helliwell <colin.helliwell@ln-systems.com>
To: yocto@yoctoproject.org,
	Alexander Kanavin <alexander.kanavin@linux.intel.com>
Subject: Re: Slightly varying builds
Date: Thu, 2 Nov 2017 16:50:40 +0000 (GMT)	[thread overview]
Message-ID: <198351249.226064.1509641440918@email.1and1.co.uk> (raw)
In-Reply-To: <872a75ce-9471-09fb-e00d-0ae5da82634a@linux.intel.com>


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


  reply	other threads:[~2017-11-02 16:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 16:43 Slightly varying builds colin.helliwell
2017-11-01 17:04 ` Alexander Kanavin
2017-11-02  7:10   ` Colin Helliwell
2017-11-02 16:26     ` Colin Helliwell
2017-11-02 16:29       ` Alexander Kanavin
2017-11-02 16:50         ` Colin Helliwell [this message]
2017-11-02 16:59           ` Alexander Kanavin
2017-11-02 17:22             ` Colin Helliwell

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=198351249.226064.1509641440918@email.1and1.co.uk \
    --to=colin.helliwell@ln-systems.com \
    --cc=alexander.kanavin@linux.intel.com \
    --cc=yocto@yoctoproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.