Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

[Alexis Ballier]

On Wed, 2 Dec 2015 23:20:05 +0000
James Le Cuirot <chewi@g.o> wrote:

> On Wed, 2 Dec 2015 12:40:08 +0100
> Alexis Ballier <aballier@g.o> wrote:
>
> > On Tue, 1 Dec 2015 22:58:55 +0000
> > James Le Cuirot <chewi@g.o> 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.