[Top][All Lists]

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

Re: Changing prefix for recursive autoconf subprojects

From: Michael Johnson
Subject: Re: Changing prefix for recursive autoconf subprojects
Date: Thu, 28 Jan 2010 15:20:18 -0500

Hi Ralf,

Thanks for the swift reply!

I feel sheepish now since I read right past that configure.gnu trick in the autoconf manual entry for AC_CONFIG_SUBDIRS. I gave it a whirl, calling the normal generated ./configure from ./configure.gnu:

./configure --prefix=${prefix}/hyrax_icu --enable-static --disable- shared

and it does the trick!

This was even a meta-solution to the problem that we needed to pass special, fixed (not from the superproject) configure options to the subproject (as in my example above the --enable-static, e.g.). I felt dirty hacking the to do it before, so I can clean that up.

Thanks very much!  This is a useful trick to know.


On Jan 28, 2010, at 1:30 PM, Ralf Corsepius wrote:

On 01/28/2010 05:29 PM, Michael Johnson wrote:
Hello autoconf gurus,

I am wondering if there is a way to modify the prefix passed down in a
recursive autoconf which uses the AC_CONFIG_SUBDIRS to recurse into

Situation: I have project A which has two subprojects B and C (which
also contain others subprojects, and A may or may not be itself a
subproject of Z, but I don't think this is relevant).

Problem: I need the recursive 'make install' on project B to install
into the prefix dir passed down by A, but I need the recursive 'make
install' on C to install into a subdirectory of A's prefix. To be
concrete, if $prefix is "/usr/local" I want B to install into
"/usr/local" but I need subproject C to install into "/usr/local/ foo". The reason is to avoid overwriting a potential existing installation of
the subproject C that may have been installed previously since we
modified the source. Unfortunately, we cannot make C a separate project
for dependency reasons.

Is there a way to append a subdirectory to the prefix passed down to one subproject but not the other with autoconf? Or is there perhaps another
way to do this that does not use autoconf?

There are several ways, unfortunately there is no simple one:

a) As you already outline, getting rid of this sub-project and relying on it being supplied externally would be the cleanest approach.

b) Use a customized macro working similar to AC_CONFIG_SUBDIRS macro internally works (normally found in /usr/share/autoconf/status.m4), but with additional argument parsing/processing added.

Though this approach definitetly initially is tedious and error prone, I have been using it in a larger project for several years and found it to be surprisingly reliable and long time stable.

c) There is a hidden feature in autoconf's AC_CONFIG_SUBDIR (cf. _AC_CONFIG_SUBDIRS in /usr/share/autoconf/status.m4 for details): If a toplevel configure finds a file called "configure.gnu" inside of a CONFIG_SUBDIR, it invokes "configure.gnu" instead of "configure". I.e. theoretically one could add a "configure.gnu" script, which would act as a wrapper script to "configure", i.e. receive the original arguments, would parse/process them and invoke the real "configure"-script in the end.

I've never tried this approach, but ... it could be worth a try.


Autoconf mailing list

Michael Johnson <address@hidden>

reply via email to

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