Bug #395633 introduced support for cross-prefix setups where EPREFIX for / differs from that for ROOT. However, the EPREFIX for / is not exposed to ebuilds in any way. I believe BPREFIX was proposed for this purpose but not implemented. Currently if one wants to execute a binary from /, they have to rely on the PATH. This may not always be possible. I am not a Gentoo Prefix user but I have been working on getting Qt ebuilds to cross-compile. I noticed that qmake-utils.eclass calls ${EPREFIX}/usr/bin/qmake for Qt4. In this instance, this should be changed to just "qmake" so that the PATH is utilised. In the Qt5 case though, qmake is located outside the PATH at /usr/lib/qt5/bin/qmake. Most other distros actually place both binaries under /usr/bin as qmake-qt4 and qmake-qt5 and that is up for discussion but a BPREFIX variable could still be useful in other cases. I have discussed this with redlizard in #gentoo-prefix.
So, the problem here is that when calling an executable that is not in the path, calling ${EPREFIX}/usr/bin/myprogram breaks on cross-prefix builds; build-time dependencies and host-dependencies may not be present in the target prefix, and may not even run if they are. Instead, the myprogram executable in the host prefix should be called. One possible solution for this is having portage set an environment variable BPREFIX (build prefix) or HPREFIX (host prefix) containing the prefix of the host system. This would need an EAPI bump, and further complicates ebuilds needing it. Another possibility is to demand that all executables called must be in the path somehow. This has a certain kind of purity to it and certainly is more elegant, and simplifies ebuilds; however, having all host tools used in ebuilds be in the path may well introduce serious complications of its own. It is not clear to me which road would be preferable, or whether other possibilities exist. Thoughts? I'm reassigning this to prefix until it is clear how best to solve this.
In terms of naming the variable, HPREFIX would tie in with HDEPEND, which is likely to be used at the same time. Not that HDEPEND is official... yet. ;)
redlizard told me to list further uses of this so here's one. It's the same qmake-utils.eclass function from before but I missed this aspect of it. In order to override the host qmake's hardcoded paths when ROOT!=/, a qt.conf file like this has to be provided. [Paths] Binaries = ${EPREFIX}/usr/bin Libraries = ${EROOT}usr/$(get_libdir)/qt4 Headers = ${EROOT}usr/include/qt4 Data = ${EROOT}usr/share/qt4 Clearly the Binaries line is affected. I didn't think that I would need to specify this line at all as the hardcoded default should be correct but it seems that merely including a [Paths] section strips all existing path information and so it tries to find binaries like uic and moc in the same directory as qmake. That's okay though, right? Wrong! Qt looks for qt.conf in the strangest places and the least awkward one is in the same directory as qmake. For that reason, I create a symlink to qmake in ${T} as I obviously can't create /usr/bin/qt.conf. This is all very convoluted but Qt's madness isn't my fault.
(In reply to James Le Cuirot from comment #2) > Not that HDEPEND is official... yet. ;) What does the "H" refer to here?
(In reply to Michael Haubenwallner from comment #4) > (In reply to James Le Cuirot from comment #2) > > Not that HDEPEND is official... yet. ;) > > What does the "H" refer to here? It refers to /, the build host. See "man 5 ebuild" for details.
(In reply to James Le Cuirot from comment #5) > > > Not that HDEPEND is official... yet. ;) > > > > What does the "H" refer to here? > > It refers to /, the build host. See "man 5 ebuild" for details. Ohw, indeed, thank you! Haven't followed the EAPI 5 development. But then we really should agree on the wording here to avoid potential confusion, be it for myself at least: On toolchain level, there is agreement on these for ages: BUILD where the current build is running on. HOST where the just created binaries will run after installing there. TARGET what architecture these HOST binaries will operate on. On portage level, currently we have these wordings: toolchain portage variables seen so far BUILD CBUILD "Host" HPREFIX BPREFIX HDEPEND(5) DEPEND(4) HOST CHOST "Target" ROOT EPREFIX DEPEND(5) RDEPEND PDEPEND TARGET CTARGET So for the portage variable namings, IMO we should kill BPREFIX in favour of HPREFIX now, even (and especially) in the cross-prefix patches.
I must admit that I found the name HDEPEND a little confusing and maybe would have preferred BDEPEND but I don't care that much as long as it works. There's a long drawn out discussion about it in bug #317337 that we should probably avoid repeating in here. :)
Having read through the entirety of the small novel that is the HDEPEND bug, I think the best solution regarding the BPREFIX/HPREFIX variable is to wait until HDEPEND will actually hit an EAPI, and then sneak BPREFIX/HPREFIX into that same EAPI proposal in a way that fits the HDEPEND solution. In the meantime, a workaround is possible. `EMERGE=$(which emerge); BPREFIX=${EMERGE%/usr/bin/emerge}` is a reliable way of finding out portage's primary prefix; we could add this to prefix.eclass if necessary.
(In reply to Ruud Koolen from comment #8) > I think the best solution regarding the BPREFIX/HPREFIX variable is to wait > until HDEPEND will actually hit an EAPI, Agreed. (In reply to James Le Cuirot from comment #0) > In the meantime, a workaround is possible. `EMERGE=$(which emerge); > BPREFIX=${EMERGE%/usr/bin/emerge}` is a reliable way of finding out > portage's primary prefix; we could add this to prefix.eclass if necessary. Actually, no: ${[BH]PREFIX} should not be visible to the ebuilds in any way, nor should an ebuild rely on "$(which emerge)" at all: There is no guarantee to have anything being installed in the same Prefix as portage itself, but PATH shall contain usr/bin:bin for each Prefix in use. Instead, 'qmake' should be found via PATH somehow, using either providing 'usr/bin/qmake-qt4' and 'usr/bin/qmake-qt5' or "$(usr/bin/qt4-config --qmake)" and "$(usr/bin/qt5-config --qmake)" or "$(usr/bin/qt4-config --prefix)/bin/qmake" or "usr/bin/qmake" identifying itself whether to call 'qmake-qt4' or 'qmake-qt5' or "pkg-config Qt4" or something else.
(In reply to Michael Haubenwallner from comment #9) > There is no guarantee to have anything being installed in the same Prefix as > portage itself, but PATH shall contain usr/bin:bin for each Prefix in use. That's why I said that this would probably be used in conjunction with HDEPEND. That provides the guarantee.
(In reply to James Le Cuirot from comment #10) > (In reply to Michael Haubenwallner from comment #9) > > There is no guarantee to have anything being installed in the same Prefix as > > portage itself, but PATH shall contain usr/bin:bin for each Prefix in use. > > That's why I said that this would probably be used in conjunction with > HDEPEND. That provides the guarantee. There isn't necessarily /the one/ HPREFIX: There might be multiple, chained HPREFIXes, showing up in PATH each.
(In reply to Michael Haubenwallner from comment #11) > There isn't necessarily /the one/ HPREFIX: > There might be multiple, chained HPREFIXes, showing up in PATH each. This path leads to the gates of madness? :|
(In reply to James Le Cuirot from comment #12) > (In reply to Michael Haubenwallner from comment #11) > > There isn't necessarily /the one/ HPREFIX: > > There might be multiple, chained HPREFIXes, showing up in PATH each. > > This path leads to the gates of madness? :| Note that the "prefix-chaining" thingy (potentially with multiple prefixes in one chain) has moved forward and renamed to "prefix-stack" (with one single parent and child prefix) utilizing EAPI 7 along bug#658572, although "prefix-stack" is not really about cross compiling.
Don't know why this is still open as it become BROOT in EAPI 7.
