Re: Changing prefix for recursive autoconf subprojects

[Ralf Corsepius]

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


Ralf