Ralf Corsepius wrote:
> On Fri, 2004-01-16 at 21:00, Tom Tromey wrote:
>> >>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
>>
>> 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.
> That's exactly the situation each sub-package underneath the (gcc,
> binutils, newlib, gdb) "ueberbaum" is facing.
>
> Each of them requires to "build some helper programs on the build
> machine, to create other parts of your program"
>
> For instance, when building a cross-gcc one-tree style,
> * the cross-binutils (target-ar, target-ld etc.) are such helper
> programs (They run on the build host).
> * from the perspective/view of the lib*-packages in gcc's source-tree,
> xgcc is such a tool.
>
>> 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.
> Well, I have been facing this issue myself. At first, it seems to be
> annoying ("What do I really need to ... it's only one file, implementing
> a little helper tool"), I had to learn it to pay off in longer terms.
>> I
>> think at least one part of this must be handled automatically,
> s/must/should/, otherwise agreed
>> and
>> that is the selection of EXEEXT, which can differ between build and
>> host.
> ACK, but I am inclined regard even as an almost marginal special case.
This corner case seems important to me.
> For simple cases, falling back to manually written make-rules using a
> handful of custom *_FOR_BUILD variables probably is the easiest way.
I don't think this is best. Consider that not everyone is using a compiler
with the same name. How do you set the $CC_FOR_BUILD without configure
macros doing it?
> Even simplier to is avoid compilation at all and implement such tools in
> a scripting language (This is what the fix*-tools/scripts in gcc do/did)
This is great until you are porting something to automake that has a
compiled build utility.
>> 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 :-).
> :-) Don't get me wrong, though it might sound as if, I am definitely not
> wanting to discourage him nor anybody else.
> It's just that I am fighting with autoconf/automake/libtools and their
> application to cross-building for years and believe to be able to
> estimate the problems/issues ahead :-)
At the very least, could we teach automake that it is doing host
compilations. I just want to rename the host specific vars in the struct
list to host_compile, host_compiler, host_ld, host_lder, host_link, and
host_linker. This would make it more explicit that they are for host
building. I have a patch that does that for the latest CVS.
wt
--
Warren Turkal
President, GOLUM, Inc.
http://www.golum.org
