[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: utility programs used during build

From: Warren Turkal
Subject: Re: utility programs used during build
Date: Sat, 17 Jan 2004 07:33:30 -0600
User-agent: KNode/0.7.2

Ralf Corsepius wrote:

> On Fri, 2004-01-16 at 21:00, Tom Tromey wrote:
>> >>>>> "Ralf" == Ralf Corsepius <address@hidden> 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.

Warren Turkal
President, GOLUM, Inc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]