On Thu, 2004-01-15 at 12:41, Warren Turkal wrote:
> Alexandre Duret-Lutz wrote:
>
> >>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > Tom> Well, really it might be nice to clean up target library
> > Tom> support, but I wouldn't recommend it unless you have a
> > Tom> real need; it is pretty messy.
> >
> > A simple way to support BUILD- and TARGET- compilations (and
> > more) could be to support per-target (I'm speaking of Makefile
> > targets here) compiler flags.
> >
> > It can be a bit verbose, especially if the BUILD-tool mixes
> > several languages. Here is an example where tool1 would be
> > built for BUILD, and tool2 for HOST.
> >
> > noinst_PROGRAMS = tool1 tool2
> > tool1_SOURCES = tool1a.c tool1b.cc
> > tool1_CC = $(CC_FOR_BUILD)
> > tool1_CXX = $(CXX_FOR_BUILD)
> > tool1_LD = $(CXXLD_FOR_BUILD)
> > tool2_SOURCES = tool2.c
> >
> > Just a thought.
>
> 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.
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.
> Does it
> not make sense to have a build_PROGRAMS target supportted internally that
> just works for compiling these build targetted binaries?
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.
Ralf
