[Openembedded-architecture] Host tools available from PATH

[Phil Blundell]

On Thu, 2017-03-09 at 11:39 +0000, Richard Purdie wrote:
> I'm sending this to ask whether people feel this is worth getting
> right
> for 2.3 and whether we should hold M3 and the feature freeze to get
> something implemented? This would assume we then are prepared to take
> the pain of actually populating these lists (I've made a start for
> OE-
> Core at least).

I think this is a fine idea in general.  I have only the very faintest
idea of what "2.3" and "M3" are so I have no opinion about those. :-)

It does seem as though this will make ASSUME_PROVIDED rather less
useful for host tools, or at least that any native thing added to
ASSUME_PROVIDED would need to be added to the whitelist as well.

> 
+# Tools needed to run builds with OE-Core
> +NATIVETOOLS = " \
> +    bash sh cut sed gcc ld git rm install which find xargs cat true
> mktemp \
> +    grep tar gzip touch cp mv basename dirname tr getopt sort awk
> head
> tail \
> +    mkdir patch uniq perl python chmod python3 ar strip expr ls make
> as \
> +    ranlib egrep echo chown cpio tee wc wget bzip2 stat date rmdir
> od
> diff \
> +    md5sum unlzma dd chrpath file pod2man gunzip python2.7 ln g++ [
> false true \
> +    uname test hostname nm objdump objcopy cmp printf env readlink
> flex gawk fgrep \
> +    expand pwd sleep diffstat chgrp flock ldd strings rpcgen ld.bfd
> du
> \
> +"

I'm not sure it's really safe to whitelist things that might be present
on some hosts and not others, otherwise you haven't really eliminated
the problem.  So it seems as though to have a truly robust solution,
what we would need to do is distil the list down to a bare minimum of
tools that the host environment must always provide (plus, as mentioned
above, maybe anything in ASSUME_PROVIDED) and then the code would need
to verify that all those tools really are present on any host.  If not
then you still run the risk of nondeterministic builds if one host
happens to have a tool that another doesn't.

There are certainly some things in your list above that don't obviously
look like they belong there.  Flex can be provided by flex-native, and
if you want deterministic builds then you need to know what version
you're getting (which would imply that you really do need to build it
from a recipe rather than picking up some random version from the
host).  I don't think anything in oe has any business calling ld.bfd on
the host directly at all: none of our native recipes ought to care
about what linker is in use since, in theory at least, the host system
might not use the GNU linker at all.

p.