From: James Le Cuirot <chewi@gentoo.org>
To: gentoo-pms@lists.gentoo.org
Subject: Re: [gentoo-pms] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable
Date: Thu, 13 Jun 2019 21:09:56 +0100 [thread overview]
Message-ID: <20190613210956.165c5961@symphony.aura-online.co.uk> (raw)
In-Reply-To: <w6g4l589nos.fsf@kph.uni-mainz.de>
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]
On Thu, 13 Jun 2019 12:30 +0100
Ulrich Mueller <ulm@gentoo.org> wrote in #gentoo-dev:
> <ulm> Chewi: tbh, I don't understand your update for ESYSROOT
> <ulm> SYSROOT is related to DEPEND/CHOST type dependencies
> <ulm> so why would you have ESYSROOT="/${BROOT}" if SYSROOT is equal to / ? <ulm> since BROOT is related to BDEPEND/CBUILD
I kind of see what you mean but I've been thinking of SYSROOT as being
more like a mechanism to choose between building against BROOT, EROOT
(previously the only two valid options), or some other unprefixed
location. There is no dedicated variable for SYSROOT's prefix so the
user cannot directly define it and it can therefore only be calculated
from BROOT when SYSROOT=/ or EROOT when SYSROOT=${ROOT}.
> <ulm> but if SYSROOT is blank, then ESYSROOT will be blank too, ignoring EPREFIX altogether? (or at least, that's how I read your patch)
What gave you that impression? The rule is that if the prefix cannot be
calculated because SYSROOT is neither / nor ROOT then we have to assume
no prefix. Where else could we get a prefix from?
You may think that we should just create that missing SYSROOT prefix
variable but consider that the distinct "somewhere else" location is
not intended for general use. In other words, you wouldn't execute
commands from it or chroot into it and therefore there is no value in
allowing it to be prefixed. Typically this location would
be /usr/${CHOST} as set up by crossdev.
I haven't forgotten about the cross-prefix case. In this scenario, both
ROOT=/ and SYSROOT=/ but BROOT and EPREFIX are different. Which prefix
do we choose? We pick EPREFIX because the prefix guys try to use the
target prefix as much as possible. Once SYSROOT has the OS headers and
libc headers, you should be able to build anything.
Does this help?
--
James Le Cuirot (chewi)
Gentoo Linux Developer
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-06-13 20:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-01 22:29 [gentoo-pms] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable James Le Cuirot
2019-06-02 6:10 ` Michał Górny
2019-06-12 22:05 ` James Le Cuirot
2019-06-02 12:28 ` Ulrich Mueller
2019-06-12 22:05 ` James Le Cuirot
2019-06-14 7:07 ` Ulrich Mueller
2019-06-13 20:09 ` James Le Cuirot [this message]
2019-06-13 22:17 ` Ulrich Mueller
2019-06-14 22:23 ` James Le Cuirot
2019-06-14 22:30 ` James Le Cuirot
2019-06-15 8:18 ` Ulrich Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190613210956.165c5961@symphony.aura-online.co.uk \
--to=chewi@gentoo.org \
--cc=gentoo-pms@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox