cross.rst

autotools var	CBUILD	CHOST
arch	native	target
-------------------	--------------	---------------------------
dep type	BDEPEND	DEPEND RDEPEND
-------------------	--------------	-------------- ------------
unprefixed path	/	SYSROOT ROOT
-------------------	--------------	-------------- ------------
relevant prefix	BROOT	EPREFIX
-------------------	--------------	---------------------------
prefixed path	BROOT	ESYSROOT EROOT
-------------------	--------------	-------------- ------------
autoconf var	---	--with-sysroot n/a
-------------------	--------------	-------------- ------------
has_version	--build-root or --bdepend	--host-root (none) or --depend (--rdepend?)

Didn't we agree to call it BDEPEND in the end? I don't mind but there seemed to be less resistance to this name.

The table looks good. I think it needs to address the prefix variables though and this is the tricky bit. I think vapier was right, we should have SYSROOT and ESYSROOT for consistency. It would be ESYSROOT that we'd need to pass to econf. I also think you were right with your BROOT suggestion.

How about this?

=================== ========== ========= ==========
autotools var         CBUILD          CHOST
------------------- ---------- --------------------
arch                  native         target
------------------- ---------- --------------------
dep type              BDEPEND   DEPEND    RDEPEND
------------------- ---------- --------- ----------
unprefixed path          /      SYSROOT     ROOT
------------------- ---------- --------- ----------
prefixed path          BROOT   ESYSROOT    EROOT
=================== ========== ========= ==========

I've been thinking about what values of SYSROOT we might support. From earlier conversations with you, I think you didn't intend for it to be different from both / and ROOT. This would require Portage to install to a third location, which would make things unnecessarily complicated.

With that ruled out, it would have to be the same as ROOT for cross builds. For native builds, the user could choose between / or ROOT. The former requires less building and gives a more minimal result but the latter is safer because you can easily run into bug #563034. Fixing that bug for SYSROOT=/ seems hard but it's probably out of PMS scope.

Not sure about that. The main purpose of supporting unprefixed paths is combining them with RHS path that has EPREFIX embedded already. I'm not sure how useful would that be in the end but I guess we could have SYSROOT/ESYSROOT for that reason.

As for BROOT, wouldn't it be equal to EPREFIX?

Of course an entirely different problem is whether we assume that all three locations are guaranteed to use the same EPREFIX. If they aren't, then we should either:

1. have only variants with prefix embedded,
2. have full set of separate prefix variables for every one of them.

In this case, I think 1. is simply better as it kinda reduces the risk of confusion (i.e. mixing wrong prefixes).

Small update: I've talked to @ulm about this, and it seems that EPREFIX must be the same for / and ROOT because we pass EPREFIX to configure, and so configure implicitly expects to find paths in /${EPREFIX}... Not sure how --sysroot affects its behavior though but I suppose reusing EPREFIX there is also a safe assumption.

The question is whether configure appends --prefix to --sysroot.