On Wed, 2 Dec 2015 23:20:05 +0000 James Le Cuirot <ch...@gentoo.org> wrote:
> On Wed, 2 Dec 2015 12:40:08 +0100 > Alexis Ballier <aball...@gentoo.org> wrote: > > > On Tue, 1 Dec 2015 22:58:55 +0000 > > James Le Cuirot <ch...@gentoo.org> wrote: > > [...] > > > > > > I raised one further point with mgorny that he feels could > > > potentially go into EAPI 7 but I think could remain an > > > implementation detail. In cases #3 and #4 (basically when > > > ROOT != / and PORTAGE_CONFIGROOT != /), the toolchain needs to > > > know how to source headers and libraries from ROOT instead of /. > > > > Use SYSROOT. ROOT has nothing to do with building. This should be > > defined in PMS though. > > In case #2, ROOT != / but SYSROOT = / so I take your point that > SYSROOT would negate the need to check which use case we're dealing > with. > > I looked into SYSROOT while I was writing cross-boss. It's used in > some crossdev scripts, most notably cross-pkg-config, but not by > pkg-config itself. It's also used in a small handful of eclasses and > other *-config scripts but that's all. Conversely, the aforementioned > libtool patch uses ROOT and I suspect many other things do too. In > practise, you need to set both. The libtool patch has probably not been updated after SYSROOT introduction. Feel free to file a bug about it. > On reflection, I'm now thinking that we should call it something less > generic. I also found that the Qt build uses SYSROOT for its own > purposes so you cannot rely on it in toolchain wrappers. ROOT is > probably just as unreliable. For that reason, I ended up using > CB_SYSROOT in cross-boss. > > I forgot to mention earlier that if ROOT were used, PMS actually > forbids it from being referenced in the src_* phases so this > restriction would need to be lifted. Relying on the toolchain's > internal sysroot is not sufficient. And PMS is absolutely right. Put simple: SYSROOT is where "sources" are installed (headers, .so, etc); think debian's -dev packages. ROOT is where packages are merged. Meaning: RDEPEND are installed to ROOT DEPEND are installed to SYSROOT (BDEPEND are installed to /) This implies that there is no guarantee at all that $ROOT is not completely empty when executing any src_* phase since RDEPEND does not need to be satisfied at that point. (this also implies that for BDEPEND to make sense, you also need a proper definition of SYSROOT in PMS) [...] > > [...] > > > CMake supports a CMAKE_SYSROOT argument that you set in the > > > toolchain file. We currently don't set this but it could easily be > > > added to cmake-utils.eclass as well as (or instead of?) the > > > similar variables that we already do set. > > > > iirc, CMAKE_SYSROOT is only for your case #4 and behaves more like > > 'build as if I had chrooted in CMAKE_SYSROOT' and thus doesn't help > > at all for cross-compilation > > Even without CMAKE_SYSROOT, since fixing the toolchain file stuff in > cmake-utils.eclass a little while back, CMake has actually been doing > a very good job of cross-compiling anyway. I doubt setting this would > make it any worse. Try it. My memories definitely tell otherwise. [...] Alexis.
