automake
[Top][All Lists]
Advanced

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

Re: Passing modified options to nested configure


From: Ralf Wildenhues
Subject: Re: Passing modified options to nested configure
Date: Thu, 7 May 2009 23:47:07 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Christian,

* Christian Rössel wrote on Thu, May 07, 2009 at 04:14:34PM CEST:
> Consider following cross-compile scenario where I want to build programs
> and libraries for the host (backend) as well as for the build
> (frontend). There are programs/libraries that should be build for the
> frontend only, for the backend only and for the frontend as well as for
> the backend. I issue following configure command
> 
> ./configure --build=powerpc64-unknown-linux-gnu
> --host=powerpc-bgp-linux-gnu CC=bgxlc CC_FOR_BUILD=xlc
> 
> which calls two configures in specific subdirs defined via
> AC_CONFIG_SUBDIRS:
> 
> if test "x${cross_compiling}" = xyes; then
>    AC_CONFIG_SUBDIRS([build-cross-frontend build-cross-backend])
>    SUBDIRS_TO_USE="build-cross-frontend build-cross-backend"
> else
>    AC_CONFIG_SUBDIRS([build-nocross])
>    SUBDIRS_TO_USE="build-nocross"
> fi

Why do you have separate config subdirs for the nocross case?
Can't they work as well with the cross cases?
Just curious, it should be possible to simplify your setup that way
(even if it could make things a bit suboptimal in the non-cross case).

> Let's concentrate on the frontend case. I put following commands into
> build-cross-frontend/configure.ac in order to use the correct compiler
> and to disable cross-compiling mode.
> 
> host_alias=${build_alias}
> host=${build}
> cross_compiling=no
> CC=${CC_FOR_BUILD}
> 
> So far, this works (BTW if there are other/better ways to accomplish
> this, please tell me).

The GCC tree solves basically the same problem as you do, so you could
peek at their sources to find out.  :-)

> Now there is a new requirement. We need to
> incorporate a third party autotools-enabled project that should be build
> only for the frontend. If I add
> 
> AC_CONFIG_SUBDIRS([new-third-party-project])
> 
> to build-cross-frontend/configure.ac, then the third-party configure is
> called with all the options build-cross-frontend/configure was called,
> especially --build=powerpc64-unknown-linux-gnu
> --host=powerpc-bgp-linux-gnu CC=bgxlc CC_FOR_BUILD=xlc.
> 
> The third-party configure switches to cross-compiling mode and uses the
> wrong compiler, hm, that's not good.
> 
> The question is, is there a way to override/modify the options that
> build-cross-frontend/configure passes to
> new-third-party-project/configure? In particular I need to override CC
> and --host. Can this be done without modifying the third-party configure.ac?

You can modify $ac_configure_args.  However, there are some caveats:

- it is not actually documented (so strictly speaking, you mess with
Autoconf internals); however, it is used by some other third-party
macros too.  It can't hurt to check for compatibility issues before
upgrading Autoconf though.

- AC_CONFIG_SUBDIRS will cause the sub configure scripts to be called
only very late in the configure script, near the very end.  Moreover,
basically all it does is
  for subdir in $all_subdirs_that_have_been_listed; do
    call configure in $subdir ...
  done

So modifying $ac_configure_args for only some of the sub configures does
not work with this macro.  You could either invent a new macro that does
the same thing as AC_CONFIG_SUBDIRS but runs strictly later, and allows
to modify $ac_configure_args right before.  More precisely, you will
need to imitate _AC_OUTPUT_SUBDIRS from the status.m4 file (and you will
be able to simplify it quite a bit).

Another way to go would be to have an intermediate configure.ac that is
provided by your project, and contains little more than
  AC_INIT
  AC_CONFIG_SUBDIRS([new-third-party-project])
  modify $ac_configure_args accordingly ...
  AC_OUTPUT


- Please be aware of the fact that the AC_CONFIG_SUBDIRS code calls the
sub configure with something like
      eval "\$SHELL \"\$ac_sub_configure\" $ac_sub_configure_args ..."

where $ac_sub_configure_args is set from $ac_configure_args but with
some changes.  The eval is necessary to allow for arbitrary arguments
(including whitespace) in the arguments, but requires that you quote
sufficiently any arguments that you change.  Again, you can look at the
_AC_OUTPUT_SUBDIRS macro for how this may be done properly.


Hope that helps.  If you end up with a reusable macro, it could be a
good addition to Autoconf.  If you have trouble writing such a macro,
feel free to ask (fits better on the autoconf list though).

Cheers,
Ralf




reply via email to

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