From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 015DE138334 for ; Fri, 14 Jun 2019 22:24:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E7324E0829; Fri, 14 Jun 2019 22:24:17 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BCBDAE0829 for ; Fri, 14 Jun 2019 22:24:17 +0000 (UTC) Received: from symphony.aura-online.co.uk (154.189.187.81.in-addr.arpa [81.187.189.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: chewi) by smtp.gentoo.org (Postfix) with ESMTPSA id A2133346113 for ; Fri, 14 Jun 2019 22:24:14 +0000 (UTC) Date: Fri, 14 Jun 2019 23:23:27 +0100 From: James Le Cuirot To: gentoo-pms@lists.gentoo.org Subject: Re: [gentoo-pms] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable Message-ID: <024EBD18-1089-4E36-A251-E52135C80625@gentoo.org> In-Reply-To: References: <20190601222921.12072-1-chewi@gentoo.org> <20190613210956.165c5961@symphony.aura-online.co.uk> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Reply-To: gentoo-pms@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/lumQa8eVkvJlSN2grjJKc8v"; protocol="application/pgp-signature" X-Archives-Salt: e25a7862-4715-4b60-b7b1-ab5c177d2c7b X-Archives-Hash: 4a279f198a2e848c70b99e4135883ad3 --Sig_/lumQa8eVkvJlSN2grjJKc8v Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On 13 June 2019 23:17:54 BST, Ulrich Mueller 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=3D"${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=3D${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=3D/myroot EPREFIX=3D/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 --Sig_/lumQa8eVkvJlSN2grjJKc8v Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPxcZ3tkwcedKm2a8EiZBXQDdMTcFAl0EHl8ACgkQEiZBXQDd MTczZxAAiIZOfOBjnGJfSxInx/Q8QJjQHLPOnr5U/riTekXiqeL2iq15LP+xxIva ak2lnGEGmYicnmohOHW1+OxlX5hQYAgSgDTzbX7cPtYAqfAsf4NqMR1wsRjzvM46 R4yNd0TsgEOCp6Ay5CnTy2bFMHhhFn4TwrV39nido6Gl+0dITCHclp1WWf0lIoC+ APgg45451gv/UdMyD8vuwjYHzAkD2KKh0dYPsRwIe/5BOOkfAJLkrqLMMNO/Tun8 lB8pl1oGN7XueAXXLAAM8pUiSx/GLPJ36djbb+aKwPefEwRh40h+wD0Ts0o1MEjF SpQTWxfcxfQFEhnJNQ/qRFc8cUzIOP0IjVaDe8lQOv2piYHkh0i2EKSd4iIM65Xf YWuuO/n6ag9ske4JNy+m4RbsRQIfE2hqU4tv4DtGLrP5mWxmAX1/WNUcJNkREPsY 7B3PJLJWvga+j79Og28fr5fxOsfudKuTQoCrn1c2tt7HLFSI/+A58ClP8hqqX0T0 agldolHgYnKhPSh4P6isLAcKsfvFwRptXVY+j7m8A26bSEZr7oc2F5BU5ds1EAGo o0eG/bOzdAclW/SmJLHcXEMaD4kPyEM9CiQsfIV/A5QsKRDRzAG2vRwH2V086zqh IYlcCrQSNK3bpem/e5HGL5LXO4TVnMfsU92eIxW1Q8V5fOjAHQM= =kZrI -----END PGP SIGNATURE----- --Sig_/lumQa8eVkvJlSN2grjJKc8v--