> and "get those settings passed down from top level" is one plausible end
> state - sharing logic implicitly that way rather than expanding it all
> locally in each target library configure script, even if expanding it
> locally for each library is useful as an intermediate stage.)
Correct me if I am wrong, but this is you agreeing with the end state I had in
mind from above, at least as one possible outcome? (I am not sure how much your
concerns are over the just intermediate state, or also the end state.) (See
below also on this.)
> names that mean different things in different directories (host versus
> target, libgcc versus other target libraries) add an extra complication to
> reading the build system code.
So I am very much at ease with this sort of thing. (Local lexical scope is
good!) In fact, it was seeing "target" in the libgcc build system at all that
threw me off, at least until I realized it worked because host == target was
guaranteed in that case (so speaking of "target" instead of "host" is just a
way to share code with the main build system without introducing more
indirection).
In general, I like "local reasoning" / telling libraries only what they "need"
to know. IMO the subproject logic that does refer to the overall build dirs is
quite convoluted, precisely because the subprojects are not in a good position
to know everything about what the overall build system is doing.
(for an example of this right at the top of libgcc's configure.ac, see
> if test "${srcdir}" = "."; then
> if test -n "${with_build_subdir}"; then
> libgcc_topdir="${srcdir}/../.."
> with_target_subdir=
> elif test -z "${with_target_subdir}"; then
> libgcc_topdir="${srcdir}/.."
> else
> if test "${with_target_subdir}" != "."; then
> libgcc_topdir="${srcdir}/${with_multisrctop}../.."
> else
> libgcc_topdir="${srcdir}/${with_multisrctop}.."
> fi
> fi
> else
> libgcc_topdir="${srcdir}/.."
> fi
so many branches!)
Now, it is possible that we could move all this stuff to the outside, but still
pass in libsubdir etc. to the inner runtime lib builds, to use the same names
externally / internally. (I am guessing this is the flavor of "get those
settings passed down from top level" you had in mind.) In this scenario, inner
libdir, incluedir, etc. would be unused, because their only use is to define
those other variables, but those are always defined externally and passed down
instead. This scenario would make people who think with the global view "this
name means the same thing everywhere" global scoping more comfortable for sure
--- I won't deny it.
But, doing that means that all the various built-in logic that comes with
Autotools around libdir, includedir etc. can no longer be taken advantaged of
so easily. Also, it would be misleading for my use-case for Nixpkgs where we
*don't* want to install into any actual libsubdir, because we are separating
different packages into different locations in a different way (namely, just
letting Nix do what it always does for this). (We would have to force-override
something like libsubdir='$(libdir)' to accomplish what we want under this
scenario.).
I would hope instead that since GCC has already "crossed the Rubicon" of having
runtime lib host = overall target, we can just solve any confusion by expanding
the existing docs on that to cover these new cases, and citing those docs
vigorously. I would be happy to do that.
John
