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
