[Openembedded-architecture] Host tools available from PATH

[Richard Purdie]

On Thu, 2017-03-09 at 15:59 +0100, Patrick Ohly wrote:
> On Thu, 2017-03-09 at 11:39 +0000, Richard Purdie wrote:
> > 
> > 
> > My patch is rather creative/evil. By adding it in layer.conf, it
> > works
> > before any real parsing happens and therefore gets injected very
> > early
> > into the process. That is good and the issues of the currently bad
> > user
> > feedback can be fixed. The downside to it is that its not user
> > extensible. If you have a missing utility that you need for local
> > changes (e.g. tasksel in my case
> tasksel or taskset? I lacked taskset myself.

I meant taskset, sorry. With the new version of the patch (see OE-
Core), I can just add HOSTTOOLS += "taskset" to local.conf.

> Anonymous python functions run before ConfigParsed, right?

No, very little runs before ConfigParsed, just inline variable python
code which is expanded.

>  They might depend on additional tools, although I can't come up with
> a specific example.
> 
> Overall approach a) sounds reasonable.

I've ended up with the ConfigParsed approach as on further inspection,
I think it meets our needs.

> Regarding that: what is "flex" needed for? My build host hasn't had
> it and I never ran into problems.

It was a mistake in the list, sorry. Its gone.

> If a tool is missing, there should be a good error message. Right
> now, I only got:
[...]

Coding error, fixed now.
        
> Some tool is needed for "bitbake -c devshell".
> 
> systemd-systemctl-native.bb needs taskset:
> 
>         ERROR: Traceback (most recent call last):
>           File "/work/poky/bitbake/bin/bitbake-worker", line 274, in
>         child
>             subprocess.check_output("taskset -pc %s %s" % (setcpu,
>         os.getpid()), shell=True)
>           File "/usr/lib/python3.4/subprocess.py", line 620, in
>         check_output
>             raise CalledProcessError(retcode, process.args,
>         output=output)
>         subprocess.CalledProcessError: Command 'taskset -pc 1 26875'
>         returned non-zero exit status 127
>         
>         ERROR: Task
>         (/work/poky/meta/recipes-core/systemd/systemd-systemctl-
> native.bb:do_configure) failed with exit code '1'
> 
> With taskset added to your list, I get:
> 
>     ....
>         WARNING: Setting to cpu 10
>         WARNING: Setting to cpu 10
>         WARNING: Setting to cpu 8
>         ...

I think you're using my branch which has other things in it such as CPU
pinning for configure tasks. Try master-next which shouldn't have these
issues.

> I had wondered how this would affect ASSUME_PROVIDED. Clearly if
> ASSUME_PROVIDED is for a certain native tool, that tool now needs to
> be added to the list. Bonus points if setting ASSUME_PROVIDED
> automatically extends the list, at least as far as known components
> are concerned.

I don't think there are any "known" issues here. There may be some
classes like icecc which need to add HOSTTOOLS definitions but I will
leave that to the users/experts in those areas.

> But what about ASSUME_PROVIDED += "libsdl-native"? That still works
> because the build host's pkg config paths explicitly gets made
> available in qemu-native's run.do_configure via qemu.inc:
> 
>         do_configure_prepend_class-native() {
>                 # Append build host pkg-config paths for native
> target since the host may provide sdl
>                 BHOST_PKGCONFIG_PATH=$(PATH=/usr/bin:/bin pkg-config
> --variable pc_path pkg-config || echo "")
>                 if [ ! -z "$BHOST_PKGCONFIG_PATH" ]; then
>                         export
> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
>                 fi
> 
> So that loophole exists only for qemu-native, right? In that case,
> other native recipes avoid potential contamination with the host's
> build files, which probably is good enough.

This is the only loophole like this I'm aware of in the core and as you
mention, it should continue to work...

Cheers,

Richard