Re: what's the state of things with pushing the bounds on ASSUME_PROVIDED?


Richard Purdie
 

On Thu, 2021-06-24 at 07:50 -0400, Robert P. J. Day wrote:
  i asked about this once upon a time, so i thought i'd follow up ...
given the fairly stable state of recent linux distros, is there any
standard for taking advantage of what *should* be robust native tools
rather than building them? (i'm ignoring taking advantage of sstate
and building SDKs and other clever speedups for now.)

  from scratch, i did a wind river (LINCD) build of
wrlinux-image-small (and i assume it would be much the same under
current oe-core), and i notice that numerous native tools were
compiled, including such standards as cmake, curl, elfutils ... the
list goes on and on.

  so other than the tools that are *required* to be installed, if i
mention that i am currently running ubuntu 20.04, is there any
indication as to which tools i'm relatively safe to take advantage
using ASSUME_PROVIDED and HOSTTOOLS? i realize that the versions built
will probably differ from the host versions, but it seems that if
there is an incompatibility, that would be fairly obvious in short
order.

  thoughts?
Quite often things aren't as simple as they first seem:

Elfutils has a history of interesting changes between versions so having 
our builds use a consistent version is good.

Some recipes build libs as well as binaries, e.g. the compression tools.
Its relatively easy to check a binary is present, it is harder to check
the right -devel headers are present. That is a solvable problem but again, 
version consistency is good. If you require a HOSTTOOLS bin but our own
lib, you can get version mismatches.

We do patch some utilities for 'reasons' and having those patches missing
can be a pain and cause weird errors.

Reproducibility is also a concern, particularly if different versions of 
tools like flex/bison generated different code.

I also wonder who is going to support testing all these different options
and handle the resulting build failures and bugs being raised?

This list isn't definitive.


In summary, I see a lot of problems for what amounts to not much speed
gain. Particularly when we have a mechanism like sstate available
which allows binary reuse.

Cheers,

Richard

Join yocto@lists.yoctoproject.org to automatically receive all group messages.