>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> 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
