[OE-core] [PATCH v2] bitbake.conf: Add sdl-config to HOSTTOOLS if using host SDL

[Jonathan Liu]

Hi Patrick,

Something is really strange. HOSTTOOLS doesn't appear to be working
anymore in pyro branch
If I do "bitbake -c devshell qemu-native", I can run the following
commands successfully which should have been filtered out by
HOSTTOOLS:

$ which sdl-config
/usr/bin/sdl-config
$ which ncdu
/usr/bin/ncdu
$ which whoami
/usr/bin/whoami

For some reason /usr/bin is contained in PATH. Previously it was filtered out.

Regards,
Jonathan

On 27 June 2017 at 19:05, Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Thu, 2017-06-01 at 22:15 +1000, Jonathan Liu wrote:
>> If ASSUME_PROVIDES contains libsdl-native, we need to add sdl-config
>> to HOSTTOOLS to allow access to the host sdl-config.
>>
>> Signed-off-by: Jonathan Liu <net147 at gmail.com>
>> ---
>>  meta/conf/bitbake.conf | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> index 8e4f4bbb56..3ad905c917 100644
>> --- a/meta/conf/bitbake.conf
>> +++ b/meta/conf/bitbake.conf
>> @@ -471,6 +471,9 @@ HOSTTOOLS += " \
>>  # Tools needed to run testimage runtime image testing
>>  HOSTTOOLS += "ip ping ps scp ssh stty"
>>
>> +# Link to sdl-config if using host SDL
>> +HOSTTOOLS += "${@bb.utils.contains('ASSUME_PROVIDES', 'libsdl-native', 'sdl-config', '', d)}"
>> +
>
> Why are you checking ASSUME_PROVIDES? The variable is called
> ASSUME_PROVIDED.
>
> Even if you had checked the right variable, is that really necessary?
> I'm building qemu with ASSUME_PROVIDED += "libsdl-native" just fine on
> Debian Jessie, without sdl-config in HOSTTOOLS.
>
> Sorry for the late reply, going through my backlog... I see that this
> has been merged. Probably needs to be reverted or fixed.
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>