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