Proposed minor build-process revamp to simplify cross-configuration

Loren James Rittle
Fri May 12 02:42:00 GMT 2000

I am not the first to observe the problems of cross-configuration
described here (I refer to configuration of various parts of the gcc
tree, not cross-target configuration and building).  [See
libstdc++-v3/docs/*/DESIGN (search for isystem) and past traffic on
gcc lists.]  Below is my proposed solution to an issue that has now
come to a head.

Here is an average command line from the dejavu testsuite for g++
with libstdc++-v2:

[Note: $(obj) and $(src) are actually fully expanded.]

$(obj)/gcc/testsuite/../g++ -B$(obj)/gcc/testsuite/../ \
$(src)/egcs/gcc/testsuite/g++.dg/special/conpr-1.C -I$(src)/egcs/libstdc++ \
-I$(src)/egcs/libstdc++/stl -fmessage-length=0 -I$(src)/egcs/libio \
-I$(obj)/i686-unknown-freebsdelf3.4/libio \
-L$(obj)/i686-unknown-freebsdelf3.4//libstdc++ \
-L$(obj)/i686-unknown-freebsdelf3.4//libiberty \
-lm -o ./a.out

If it worked (unfortunately, what I display below is too simplistic
and I have been fighting this problem of being able to test in place
before installation for some time now), here would be an average
command line from the dejavu testsuite for g++ with libstdc++-v3:

[Note: $(obj), $(src), $(os) and $(ctype_style) are actually fully expanded.]

$(obj)/gcc/testsuite/../g++ -B$(obj)/gcc/testsuite/../ \
$(src)/egcs/gcc/testsuite/g++.dg/special/conpr-2a.C \
-I $(obj)/i686-unknown-freebsdelf3.4//libstdc++-v3 \
-I $(obj)/i686-unknown-freebsdelf3.4//libstdc++-v3/libio \
-I $(src)/egcs/libstdc++-v3/config/$(ctype_style) \
-I $(src)/egcs/libstdc++-v3/config/cpu/$(cpu) \
-I $(src)/egcs/libstdc++-v3/std \
-I $(src)/egcs/libstdc++-v3 \
-I $(src)/egcs/libstdc++-v3/libio \
-I $(src)/egcs/libstdc++-v3/backward \
-I $(src)/egcs/libstdc++-v3/ext \
-I $(obj)/i686-unknown-freebsdelf3.4//libstdc++-v3/../../gcc/include \
-fmessage-length=0 -c -o conpr-2a.o

Now, it is interesting to note that 'gcc -Bpath/' alone does almost
precisely what we want in order to test the tree before we install
into the final location, if and only if, we force all packages being
built with gcc to offer some sort of pre-install of headers (and maybe
libraries) into a tree structure that mirrors the final tree structure
but held within $(obj).  We don't do that today.  Currently, libraries
are allowed to just sit in their own little source trees forcing the
rest of the tree to understand their internal structure until we tell
them to install themselves in the final resting place.  As you can
see, we have further complications.  Without exposing more internal
configuration detail, only libstdc++-v3 knows all the paths it wants
to use to find headers until there are installed.  Allowing gcc to
learn of the configuration would require additional work and doesn't
allow us to leverage -B to a full extent.

What am I talking about?  If we rely on 'gcc -Bpath/' more, an average
command line from the dejavu testsuite for g++ could look like this:

$(obj)/gcc/testsuite/../g++ -B$(obj)/gcc/testsuite/../ \
$(src)/egcs/gcc/testsuite/g++.dg/special/conpr-2a.C \
-fmessage-length=0 -c -o conpr-2a.o

As a nice side benefit to being shorter (I don't know about you, but I
dread closely inspecting g++.log), notice that it could be the same no
matter what libraries (or version of libraries) are built since the
libraries themselves could put what they need to expose into the tree
form used by 'gcc -Bpath/'.  As already mentioned those libraries
already know how to install their headers and libraries into the right
form, so this new approach shouldn't need a lot of work.  It should
work to close cross-tree dependencies instead of creating new ones.
This is a good thing.

Therefore, I propose, in order that we might (a) ease the eventual
libstdc++ transition, (b) ease the eventual integration of other core
libraries such as libgcj, and (c) minimize the cross-knowledge buried
in dejagnu and parts of the gcc tree unrelated to any given library,
that we use a slightly improved 'make bootstrap' (of course for those
that always attempt to cheat the system and fail to do a full
bootstrap, we could expose the piecemeal target).  All existing
bootstrap steps stay the same.  We add a new step after all existing
bootstrap steps to recursively call a new preinstall (exact name is
debatable) target.  It would be the responsibility of each library and
gcc itself to install/stage/copy/soft-link/whatever everything it
would have put under $(prefix) had this been a real install into the
'gcc -Bpath/' compatible subtree under $(obj).

Final point, I said earlier that "'gcc -Bpath/' alone does almost
precisely what we want".  For 'g++ -Bpath/', it currently reverses the
search order of gcc and g++ headers from how 'g++' alone ordered them.
My study reveals that this reordering *would* adversely affect g++
compilations.  I think that this is an obvious bug with the g++
driver, but it would have to be fixed nonetheless.



More information about the Libstdc++ mailing list