[OE-core] why conditional assignment of DEPLOY_DIR_IMAGE in bitbake.conf?

Mark Hatle mark.hatle at windriver.com
Tue Jul 22 17:04:04 UTC 2014


On 7/22/14, 11:53 AM, Robert P. J. Day wrote:
> On Tue, 22 Jul 2014, Christopher Larson wrote:
>
>>
>> On Tue, Jul 22, 2014 at 9:36 AM, Robert P. J. Day <rpjday at crashcourse.ca> wrote:
>>          quite possibly another silly question, but i'm perusing poky's
>>        version of bitbake.conf and i see this:
>>
>>        DEPLOY_DIR ?= "${TMPDIR}/deploy"
>>        DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
>>        DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
>>        DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
>>        DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
>>        DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images/${MACHINE}"
>>        DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
>>
>>          now, what is the value of using "?=" to set DEPLOY_DIR_IMAGE, rather
>>        than just "=". i know what "?=" represents, but i normally expect to
>>        see it in a context where someone might have set it earlier to some
>>        other value, but this is in bitbake.conf, before any of the "include"
>>        or "require" directives to pull in any of the other .conf files. so in
>>        the midst of all those other DEPLOY_DIR_* hard assignments, why is the
>>        images directory a conditional install?
>>
>>
>> s/install/define/
>
>    um, quite so. :-P
>
>> If there's a ?= done before any includes in bitbake.conf, either its
>> position in the file has changed, or it's set that way to allow the
>> user to add those variables to the env whitelist and set them in the
>> environment, as the env is set before bitbake.conf is parsed.
>
>    ah, gotcha. so the obvious question is, who decides which variables
> merit this sort of behaviour and which don't? why two variables out of
> the DEPLOY_DIR_* variables and not the rest? seems sort of arbitrary.

Who, whoever sends patches with a need.

I know I've used both the DEPLOY_DIR and DEPLOY_DIR_IMAGE before to simplify a 
few things on the command line.. (but I don't use them regularly).

The others being based on those have not caused me problems the few times I've 
wanted to override it from the command line.

--Mark

> rday
>
>
>




More information about the Openembedded-core mailing list