Building cross-compilers with sibling package trees

[Eric Christopher]

> [It's not a real scenario of course, but it does have the right flavor
> of the problem I wish to solve.]
> It's the day-to-day development of a fresh port that I want to speed up.
> If I've gone through a run of "make check-gcc" and fixed some random
> bugs, with fixes in any or all of libgloss, bfd, or gcc, for example,
> I'd prefer it if I could just type make and then make check-gcc again.

Right, what I do is this:

mkdir tmp
cd tmp
mkdir gcc
cd gcc
cvs co gcc-full
cd ..
mkdir binutils
cd binutils
cvs co binutils newlib gdb
cd ..
./make-combined.sh
mkdir build
cd build
../combined/configure ...
make
make check-gcc

where make-combined.sh has:

#!/bin/sh
rm -rf combined
mkdir combined
cd combined
ln -s ../gcc/gcc/* .
ln -s ../binutils/src/* . > /dev/null 2>&1
rm include
mkdir include
cd include
ln -s ../../gcc/gcc/include/* .
ln -s ../../binutils/src/include/* . > /dev/null 2>&1

and this works for my day to day development for a full combined tree.
It basically constructs it on the fly out of the two checkouts.

I think from talking to you at the summit though that you don't want to
script this bit of it, but that it could magically find all of the
relevant pieces or at least be able to specify it on the command line.
I'm not against additional configury hacks to specify the location of
each of the various source directories, i just think it's more effort
than it's worth when a combined tree is guaranteed to work.. at least
for day to day development - i wouldn't suggest taking an ancient
release of one thing and merging with a new one without paying attention
to which one overwrites the other.

-eric