Re: Changing prefix for recursive autoconf subprojects

[Michael Johnson]

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 configure.in to do it before, so I can clean that up.

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

Michael


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
> > 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
>
>
>
> _______________________________________________
> Autoconf mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/autoconf

-----------------------------------------------------------------
Michael Johnson <address@hidden>
OPeNDAP, Inc.