| 1 |
On 13 June 2019 23:17:54 BST, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
>EPREFIX will be embedded into any (CHOST) binaries being built, so we |
| 4 |
>want it to be applied in the same way for both DEPEND and RDEPEND, |
| 5 |
>right? Why would it be appended to ROOT then, but not to SYSROOT? |
| 6 |
> |
| 7 |
>Also I still don't understand why BROOT (which points to the CBUILD |
| 8 |
>system) would be used as a prefix for CHOST things. |
| 9 |
|
| 10 |
What do you think SYSROOT is actually used for? As things stand, I'm |
| 11 |
aware of: |
| 12 |
|
| 13 |
* cross-pkg-config uses it to source .pc files within SYSROOT and the |
| 14 |
results are adjusted using ${PKG_CONFIG_SYSROOT_DIR}. |
| 15 |
* econf adds --with-sysroot="${ESYSROOT:-/}" when the package is built |
| 16 |
with libtool as that is the only component that uses it. |
| 17 |
* A small handful of ebuilds. |
| 18 |
* My pending Python eclass changes. |
| 19 |
|
| 20 |
If you want to build against a different SYSROOT than the one the |
| 21 |
toolchain defaults to then you also need to add --sysroot=${ESYSROOT} |
| 22 |
to CC and friends. cross-boss does this for you. I didn't do this in my |
| 23 |
earlier prefix example because I was focusing on pkg-config. |
| 24 |
|
| 25 |
Most of the above relates to locating headers and libraries within |
| 26 |
SYSROOT to be built against, usually with -I and -L flags. They may |
| 27 |
have been built using a different prefix but so what? The SYSROOT |
| 28 |
libraries are not the ones that will be used at runtime; those are |
| 29 |
built and installed separately into ROOT to satisfy RDEPEND. There are |
| 30 |
admittedly a few headers that hard code prefixed paths but these are |
| 31 |
the exception. |
| 32 |
|
| 33 |
Remember that the only case where we're potentially forcing the prefix |
| 34 |
to be different is the distinct SYSROOT case where it has to be blank. |
| 35 |
That case is primarily just for getting the OS headers and libc in |
| 36 |
place. We're not stopping users from using the same prefix for BROOT and |
| 37 |
EPREFIX if they want to. Conversely, we're not stopping them from using |
| 38 |
different prefixes right now either and that's been true since prefix |
| 39 |
was introduced. You've always been able to do this from a system with a |
| 40 |
different (or blank) prefix: |
| 41 |
|
| 42 |
ROOT=/myroot EPREFIX=/myprefix emerge foo |
| 43 |
|
| 44 |
Without any additional measures in place, this would build against |
| 45 |
the build system's libraries and headers, despite the different prefix. |
| 46 |
All we're doing now is formalising it around the ESYSROOT variable. |
| 47 |
|
| 48 |
If you think this is too confusing or prone to breakage then we could |
| 49 |
add a restriction that forces SYSROOT's prefix to be EPREFIX but this |
| 50 |
would be a largely artificial restriction. We would have to change |
| 51 |
crossdev to install to /myprefix/usr/${CHOST}/myprefix rather than |
| 52 |
just /myprefix/usr/${CHOST} and I fear that could get messy. |
| 53 |
|
| 54 |
I don't personally use prefix so I don't really have a horse in this |
| 55 |
race. We're also talking about fairly edgy edge cases here. I've never |
| 56 |
heard of any prefix users using ROOT. I just want to make sure our |
| 57 |
package manager is built on solid standards that make sense. I also |
| 58 |
want to do right by the prefix guys. |
| 59 |
|
| 60 |
Cheers, |
| 61 |
Chewi |
Archives