Hi James,

Sorry that I have re-ordered your text.

> A check was added to Portage to ensure this held. Myself, the
> ChromiumOS team, and others have since been caught out by this check
> when trying to bootstrap brand new systems from scratch. You cannot
> bootstrap with no headers at all! The check will therefore be adjusted
> to merely ensure that SYSROOT is / when ROOT is /.

It is very encouraging to see contributions from the ChromiumOS team to
Gentoo!

> What if we want to bootstrap a brand new prefixed system using the
> crossdev system as SYSROOT? This is the distinct SYSROOT case. The
> problem is that there is no distinct variable for SYSROOT's prefix
> and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
> therefore cannot do it! If the crossdev prefix is blank then ROOT's
> must be blank too.

My question: is there a case when both SYSROOT and ESYSROOT are needed?
As far as I can see, SYSROOT is strictly build-time. Therefore setting
SYSROOT=<crossdev toolchain path> would be enough for all.

Why did ESYSROOT exist in the first place?  Was it only for the sake of
symmetry, or did I miss something?

> It was originally envisaged (but not stated in PMS) that SYSROOT would
> only ever need to equal / or ROOT as a distinct SYSROOT would have no
> benefit.
...
> There were differing assumptions about how prefixes applied to the
> above. EPREFIX is traditionally something the user sets so some
> thought that it would be applied to SYSROOT, regardless of the
> latter's value. In order to honor the rule about there being no
> distinct SYSROOT, this would mean that if SYSROOT is / then EPREFIX
> would have to match BROOT.
...
> I also never intended to have the aforementioned limitation where
> EPREFIX must match BROOT when SYSROOT is /. These are both entirely
> artificial restrictions.

I agree. This is an artificial restrictions.

> What about the cross-prefix case? Here, SYSROOT matches both / and
> ROOT so which prefix do we choose? The bootstrap-prefix.sh script sets
> flags to build against the target prefix so EPREFIX is used in this
> case. This happens to fit the current definition of ESYSROOT anyway.

In this bootstrap case, SYSROOT=EPREFIX would do.  Again, no ESYSROOT is
needed.


In conclusion, IMHO, if SYSROOT can be overridden without restriction
("distinct" in your email), we could cover all the use cases.

Yours,
Benda

Reply via email to