We've had quite a long talk about cross support in Gentoo yesterday, and one of the conclusions is that we should start by describing what SYSROOT is now and how it's used. AFAIU it's meaningful not only in the cross-case but also in regular builds. If I'm not mistaking anything, SYSROOT is the root where packages from DEPEND are expected to be installed. As such, the variable is meaningful in all src_* phases (and we don't have to make ROOT meaningful there). My questions would be: 1. How does SYSROOT operate with EPREFIX? Is it assumed to be prefixed appropriately already? Or are we supposed to use ${SYSROOT}${EPREFIX}"? If the latter, do we want to force the same EPREFIX for ROOT and SYSROOT? 2. Should SYSROOT be available in pkg_* phases? I think not, since DEPEND is not guaranteed to be satisfied there. 3. Should we add implicit --sysroot support in econf? (conditional to --help alike other new thingies there)
(In reply to Michał Górny from comment #0) > 1. How does SYSROOT operate with EPREFIX? Is it assumed to be prefixed > appropriately already? Or are we supposed to use ${SYSROOT}${EPREFIX}"? If > the latter, do we want to force the same EPREFIX for ROOT and SYSROOT? Good question. Current usages of SYSROOT in tree don't seem to agree on this. Use $SYSROOT$EPREFIX I'd say: SYSROOT (or any substring of it) should not "leak" into resulting binaries. EPREFIX is especially meant to "leak". I don't think we should "force" any EPREFIX value but leave PM define whatever it wants. It's likely PM will use a different configuration with SYSROOT!=/, for CFLAGS & co, so why not EPREFIX too. > 2. Should SYSROOT be available in pkg_* phases? I think not, since DEPEND is > not guaranteed to be satisfied there. +1. SYSROOT should be only available when DEPEND is satisfied. > 3. Should we add implicit --sysroot support in econf? (conditional to --help > alike other new thingies there) Not sure there, I've never needed that, but it's probably worth it. cmake-utils already does things like that. CC'ing vapier & solar since I think they'd know best SYSROOT stuff.
(In reply to Michał Górny from comment #0) SYSROOT was designed/implemented before prefix existed. it was the parallel to the ROOT variable which, at the time, meant the same thing as EROOT. if we want to keep the parallels going, we'd probably want SYSROOT/ESYSROOT. automatic adding of --sysroot to econf would probably be helpful. it's starting to make its way into more autoconf tools as people rebuild. (In reply to Alexis Ballier from comment #1) in general i'd agree about SYSROOT leaking, but there are a few cases currently where it shows up in tools that are kind of crappy to begin with. the biggest example off the top of my head is apr & apr-util -- they provide a few scripts that other apache related packages run to figure out the compiler/tool settings to build code. we leak SYSROOT into those because otherwise they'd just use / directly. the ideal would be to rework those packages, but it'll be a while before we can. so it'd be a strong recommendation to not leak SYSROOT (at least in a functional manner -- including in --help or --version info is generally fine), but being practical it wouldn't be a hard block.
SYSROOT used in next ebuilds: app-admin/apache-tools dev-libs/apr-util dev-libs/boost dev-libs/log4cxx dev-ros/xmlrpcpp net-fs/samba net-libs/serf net-wireless/crda sci-geosciences/gpsd sci-libs/ViSP sys-apps/ucspi-unix sys-boot/elilo sys-libs/libspe2 So what we decide todo next? :)
I suspect mgorny wanted my input here. Java keeps me busy. I'll try to write something later today.
(In reply to Michał Górny from comment #0) > 1. How does SYSROOT operate with EPREFIX? Is it assumed to be prefixed > appropriately already? Or are we supposed to use ${SYSROOT}${EPREFIX}"? If > the latter, do we want to force the same EPREFIX for ROOT and SYSROOT? I'm with Mike on this one, it pre-dates our prefix stuff and it's not really a Gentoo concept anyway. > 2. Should SYSROOT be available in pkg_* phases? I think not, since DEPEND is > not guaranteed to be satisfied there. No, I really can't think why that would be necessary. > 3. Should we add implicit --sysroot support in econf? (conditional to --help > alike other new thingies there) Yes! Obviously I'm in favour of this one. ;) With cross-boss, I checked for lt_sysroot in the configure source but --help seems less likely to result in a bogus match.
Just found this bug and now I am curious if this can make it into the next EAPI? Especially implicit adding of --sysroot in econf phase, that would solve a lot cross build problems.
(In reply to Joakim Tjernlund from comment #6) > Just found this bug and now I am curious if this can make it into the > next EAPI? > > Especially implicit adding of --sysroot in econf phase, that would > solve a lot cross build problems. That is my intention and I've been asked to take this further. Trying to find the time.
(In reply to James Le Cuirot from comment #7) > (In reply to Joakim Tjernlund from comment #6) > > Just found this bug and now I am curious if this can make it into the > > next EAPI? > > > > Especially implicit adding of --sysroot in econf phase, that would > > solve a lot cross build problems. > > That is my intention and I've been asked to take this further. Trying to > find the time. Good :) I do hope "--sysroot in econf phase" will be usable in existing EAPIs? Most ebuilds does not use/care about SYSROOT so these will just work.
Ping. Is there any progress on this? Should we count it for EAPI 7?
(In reply to Michał Górny from comment #9) > Ping. Is there any progress on this? Should we count it for EAPI 7? I consider your questions answered, not sure what else is needed.
My questions were merely suggestions what needs to be covered. What needs to happen right now is someone has to either prepare a proper PMS patch for it, or at least a concise summary of what needs to be added and where.
Let's go for a combined proposition since proper explanation of the relations between variables require BDEPEND anyway. *** This bug has been marked as a duplicate of bug 317337 ***
