On 13 June 2019 23:17:54 BST, Ulrich Mueller <ulm@gentoo.org> wrote:
>
>EPREFIX will be embedded into any (CHOST) binaries being built, so we
>want it to be applied in the same way for both DEPEND and RDEPEND,
>right? Why would it be appended to ROOT then, but not to SYSROOT?
>
>Also I still don't understand why BROOT (which points to the CBUILD
>system) would be used as a prefix for CHOST things.

What do you think SYSROOT is actually used for? As things stand, I'm
aware of:

* cross-pkg-config uses it to source .pc files within SYSROOT and the
  results are adjusted using ${PKG_CONFIG_SYSROOT_DIR}.
* econf adds --with-sysroot="${ESYSROOT:-/}" when the package is built
  with libtool as that is the only component that uses it.
* A small handful of ebuilds.
* My pending Python eclass changes.

If you want to build against a different SYSROOT than the one the
toolchain defaults to then you also need to add --sysroot=${ESYSROOT}
to CC and friends. cross-boss does this for you. I didn't do this in my
earlier prefix example because I was focusing on pkg-config.

Most of the above relates to locating headers and libraries within
SYSROOT to be built against, usually with -I and -L flags. They may
have been built using a different prefix but so what? The SYSROOT
libraries are not the ones that will be used at runtime; those are
built and installed separately into ROOT to satisfy RDEPEND. There are
admittedly a few headers that hard code prefixed paths but these are
the exception.

Remember that the only case where we're potentially forcing the prefix
to be different is the distinct SYSROOT case where it has to be blank.
That case is primarily just for getting the OS headers and libc in
place. We're not stopping users from using the same prefix for BROOT and
EPREFIX if they want to. Conversely, we're not stopping them from using
different prefixes right now either and that's been true since prefix
was introduced. You've always been able to do this from a system with a
different (or blank) prefix:

ROOT=/myroot EPREFIX=/myprefix emerge foo

Without any additional measures in place, this would build against
the build system's libraries and headers, despite the different prefix.
All we're doing now is formalising it around the ESYSROOT variable.

If you think this is too confusing or prone to breakage then we could
add a restriction that forces SYSROOT's prefix to be EPREFIX but this
would be a largely artificial restriction. We would have to change
crossdev to install to /myprefix/usr/${CHOST}/myprefix rather than
just /myprefix/usr/${CHOST} and I fear that could get messy.

I don't personally use prefix so I don't really have a horse in this
race. We're also talking about fairly edgy edge cases here. I've never
heard of any prefix users using ROOT. I just want to make sure our
package manager is built on solid standards that make sense. I also
want to do right by the prefix guys.

Cheers,
Chewi