automake
[Top][All Lists]
Advanced

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

Re: utility programs used during build


From: Ralf Corsepius
Subject: Re: utility programs used during build
Date: Fri, 16 Jan 2004 05:26:25 +0100

On Thu, 2004-01-15 at 22:02, Warren Turkal wrote:
> Ralf Corsepius wrote:
> 
> > On Thu, 2004-01-15 at 12:41, Warren Turkal wrote:
> >> This assumes that something sets those variables still (autoconf).
> > 
> > Just add something similar to this
> > CC_FOR_BUILD=${CC_FOR_BUILD-${CC})
> > or
> > AS_IF([$build != $host],
> > [CC_FOR_BUILD=${CC_FOR_BUILD-cc],
> > [CC_FOR_BUILD=$CC])
> > to your configure.ac.
> 
> Then you are still manually setting up this stuff.
Yes, these are hacks or to put it a bit more politely "shortcuts for
simple cases".

> > If you additionally split build-compiled tools into a separate directory
> > + Makefile.am which contains CC = @CC_FOR_BUILD@ you can use
> > automake-generated rules there.
> > 
> > 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.
> 
> This is just a hack.
Definitely no.

>  I have seen this solution proposed before.
This is the current nominal working principle, as it is applied by
packages which actually support cross-compilation (gcc, newlib,
binutils, gdb etc.).

>  It is not
> conceptually another package. Why treat it that way? I would like to have
> one configure script per package.
Why? A package may consist of multiple subpackages, can contain several
configure-scripts etc.

Also, splitting a package into build- and host- compiled packages
prepares a "large package" for multiple host-building and
Canadian-Crosses (This is the case where you actually need --target).

I guess, you've already read http://www.airs.com/ian/configure

> > automake isn't the actual problem. The actual problem is autoconf
> > support for build-compilation, because supporting build- and host-
> > compilation/checks would require to duplicate almost all autoconf
> > checks/variables etc.
> 
> Automake is part of the problem.
Yes, but ... I expect these to be negligible in comparison to those
you'll probably encounter with autoconf (Think about AC_CONFIG_HEADERS).

Ralf






reply via email to

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