Building a cross compiler from scratch "just works" (as in all one
has to do is "configure, make all install") if all of binutils, gcc,
newlib, libgloss, libstdc++, etc. are siblings.
[At least this use to "just work".]
The number of hoops one has to go through when this isn't the
case can be painful, especially if one is doing active development
on multiple packages (e.g. writing a new port from scratch).
Is there any interest in making this easier?
[where "this" = keeping packages separate but still having
the convenience of a "one-tree" layout]
If not, there's no point in reading further. :-)
I was thinking that (at least) two things are required:
1) the ability to tell gcc where the other packages are
2) the ability to build gcc, build libc (e.g. newlib), then come
back and build libstdc++
For (1), the tree layout might be something like
topsrc/Makefile.in
topsrc/configure.ac
topsrc/configure
topsrc/$binutils/gas
/binutils
/other-binutils-subdirs
topsrc/$gcc/gcc
/libstdc++-v3
/other-gcc-subdirs
topsrc/$newlib/newlib
/libgloss
/other-newlib-subdirs
topsrc/$etc
If there were configure arguments (or some such) to tell gcc
where to find gas (for example) in this new build tree,
then one could continue to have a "one tree" like tree,
and topsrc/Makefile.in could orchestrate building of everything.
For (2), libstdc++-v3 needs to know where the libc headers are,
in the build tree. If libc is newlib, then at least part of
newlib needs to be made first (so that targ-include is created)
before configuring/building libstdc++-v3.
I think topsrc/Makefile.in can easily orchestrate cd'ing into gcc
to build gcc, cd'ing into newlib to build newlib, and then cd'ing
back into gcc to build libstdc++-v3, but it is a bit of a dance.
So, to repeat in case I lost you, is there any interest in making this easier?
[where "this" = keeping packages separate but still having
the convenience of a "one-tree" layout]
Or, if one is writing a new port from scratch,
do we just tell folks to either manually hack in a "one-tree" layout
or otherwise deal with it by him/herself.
Most of the solution is outside the scope of each package, which is good,
so one might wonder why bother gcc with this. Some change to gcc would
be required to allow it, for example, to create its gas symlink to a different
place in the build tree (beyond the current default of ../gas/as-new).
