Re: utility programs used during build

[Tom Tromey]

>>>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

>> > If you want a clean way, you'd have to split buildtools and
>> > host-packages into separate (sub) packages and write a costomized
>> > toplevel configure-script to parse and set the configure options for
>> > build- and host- compile packages.

Ralf> This is the current nominal working principle, as it is applied by
Ralf> packages which actually support cross-compilation (gcc, newlib,
Ralf> binutils, gdb etc.).

Hmm, I think we're mixing scenarios.

In gcc, for instance, ordinarily target libraries are put in their
own directories with their own configuration.  And there is also a
surrounding layer of hackery to deal with multilibs.

But that isn't what Warren is talking about.  He's talking about a
situation where you want to build your package for a different host,
but first build some helper programs on the build machine to create
other parts of your program.

E.g., in gcc there are the gen* family of programs, like genattrtab.
These are just incorporated in the gcc source directory along with
files that will be compiled for the host machine, not the build
machine.


My opinion on this is that total separation is easier to implement,
but not really cleaner.  "Clean" depends on the needs of the package
at hand, sometimes you'd really rather just lump all the sources
together.


Alexandre's simple solution of overriding _CC and the like is nice.  I
think at least one part of this must be handled automatically, and
that is the selection of EXEEXT, which can differ between build and
host.  And really my preference would be to have it all done
automatically, since that is easier for the user and less
error-prone... still, it looks like the same internal mechanisms are
necessary to support build compilers and per-target compilers.

Anyway, it looks like there's a big job ahead for Warren :-).

Tom