Re: utility programs used during build

[Ralf Corsepius]

On Fri, 2004-01-16 at 21:00, Tom Tromey wrote:
> >>>>> "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.
I don't think so.

> 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.
Yes, you are referring to $target_subdir

> 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.

> 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.
Yes, these are set of tools inside of the source-tree, not applying the
approach I am talking about.

> My opinion on this is that total separation is easier to implement,
Agreed, I am convinced, that not applying the "split-package" approach
will be costly in longer terms.

[Have a look at gnatlib in gcc. The Ada-folks prefer to not split out
their sources and prefer to lump together gnatlib with the rest of gnat.
Consequence: in gcc-3.3.* gnatlib can't be cross-built properly (If it
does on a particular build system, it is just a random accident, because
build system and host system are similar enough for not causing
conflicts.)]

> 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.

> Alexandre's simple solution of overriding _CC and the like is nice.
That's not what I am referring to. I am referring to gcc's toplevel
configure script (The old "cygnus configure") and it's internal working
principle:

mkdir $target_subdir/$package
cd $target_subdir/$package;
CC=$CC_FOR_TARGET ... <builddir>/$package/configure

This approach fits cleanly into the autoconf's working principles,
doesn't conflict with automake/libtool. 
All that lacks to make this handy basically is
"BUILD|HOST|TARGET_CONFIG_SUBDIR" support in autoconf and "make dist"
support in automake.

>   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.

IMO, the real problems are lurking in AC_TRY_COMPILE/LINK and AC_DEFINE
and everything based on them.

AC_TRY_COMPILE/LINK with the build or host compiler? Where to store
AC_DEFINEs, build or host CONFIG-header? And how to pass on INCLUDES,
LIBS, DEFS, CPPFLAGS, CFLAGS, CXXFLAGS, LDFLAGS etc.?

For simple cases, falling back to manually written make-rules using a
handful of custom *_FOR_BUILD variables probably is the easiest way.

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)

>   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 :-)

Ralf