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
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
-----------------------------------------------------------------
Michael Johnson <m.johnson@xxxxxxxxxxx>
OPeNDAP, Inc.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
