[OE-core] [PATCH] runqemu: take TMPDIR from bitbake

Anders Darander anders at chargestorm.se
Tue Jun 14 10:33:22 UTC 2011


On Tue, Jun 14, 2011 at 11:25, Yury Bushmelev <jay4mail at gmail.com> wrote:
> 2011/6/14 Anders Darander <anders at chargestorm.se>:
>> On Tue, Jun 14, 2011 at 00:22, Yury Bushmelev <jay4mail at gmail.com> wrote:
>>> Getting some variable from bitbake is frequently used task. May be our
>>> bitbake people will add some special mode to bitbake for this? E.b.
>>> like bsd make have (make -V KERNCONF)[1].
>>>
>>> I would suggest syntax like 'bitbake -V TMPDIR'
>>
>> That would definitely simplify a few lines in a number of scripts.
>
> Note that user may request more than one variable with single bitbake
> invocation. E.g.:
>
> bitbake -V TMPDIR -V DEPLOY_DIR
>
> In this case better to prefix variable value with name, like set does:
>
> TMPDIR=/path/to/tmpdir
> DEPLOY_DIR=/path/to/deploydir

The question is, how often do we assume that multiple variable will be
requested?

Sure, if we need multiple variables, we'll save time by only invoking
bitbake (and parse all configs, etc) once. On the other hand, have we
then gained anything, as compared to 'bitbake -e'? Sure, we'll reduce
the output, by only outputing the requested variables... But in the
original case: TMPDIR=`bitbake -e | grep TMPDIR=\" | cut -d '=' -f2 |
cut -d '"' -f2`
the only change we can do is to substitute 'bitbake -e' with 'bitbake
-V TMDPDIR', which wouldn't be any improvement.

Or should `bitbake -V TMPDIR` only output '/path/to/tmpdir', and
`bitbake -V TMPDIR -V DEPLOY_DIR`output
TMPDIR=/path/to/tmpdir
DEPLOY_DIR=/path/to/deploydir
i.e. only prefix the variable value if more than one variable is requested?

I'd like `bitbake -V TMPDIR` to only output the value, as otherwise we
can just use `bitbake -e` anyway. If we make  `bitbake -V TMPDIR` only
output the value, then the question is should we only allow a singel
'-V VARIABLE', or should we accept multiple variables, and then prefix
the values?

Regards,
Anders




More information about the Openembedded-core mailing list