Discussion:
Multiple subdirectories with non-similar configure needs
Jim Galarowicz
2011-03-28 19:08:02 UTC
Permalink
Hi,

I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements. I searched the autoconf archives
but didn't get any relevant matches, but I may not have used the correct
search parameters.

I have three directories (and plan to add more) that I would like to
configure from the top-level directory. However, the way I am using
autoconf is forcing the same configure line to be used on all three
directories. Is there a way to have an autoconf/automake/libtool
top-level directory and have the configures for each subdirectories be
different? Basically, throw control to the subdirectories and allow
them to configure individually? AC_CONFIG_SUBDIRS doesn't seem to be
the right specification.

The goals for this project are to have the subdirectories (libraries)
able to be configured and built individually. For convenience, we
would like to have a top-level configure that would configure and build
all the libraries.

My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet. Each
subdirectory has different package requirements and has been set up to
use autoconf, automake, libtool, m4, etc..

I bootstrap using these commands:
aclocal --force -I m4
libtoolize --copy --force --ltdl
autoheader --force
automake --add-missing --copy --force-missing --foreign
autoconf

My configure.ac:
AC_PROG_CXX
AC_PROG_LIBTOOL
AC_PROG_INSTALL

LT_CONFIG_LTDL_DIR([libltdl])
LT_INIT([dlopen])
LTDL_INIT([recursive])

...
<host specific code>
...

AC_CONFIG_SUBDIRS(libcbtf)
AC_CONFIG_SUBDIRS(libcbtf-xml)
AC_CONFIG_SUBDIRS(libcbtf-mrnet)

AC_CONFIG_FILES([Makefile])

AC_OUTPUT


Any pointers would be greatly appreciated.

Thanks,
Jim G.
Ralf Wildenhues
2011-03-29 06:35:50 UTC
Permalink
Hello Jim,
Post by Jim Galarowicz
I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements.
Well, you can just write code yourself that calls the sub configure
scripts with the arguments you intend for it. Basically your own
version of AC_CONFIG_SUBDIRS, if you like.

GCC does this in its own tree (except the code is partly in the
makefile, not only the toplevel configure script).

For simple things, it often suffices to adjust $ac_configure_args during
configure (beware of the eval quoting though!).

However, you haven't written what kind of adjustments you need at all,
so it's not clear how to help more.
Post by Jim Galarowicz
My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet. Each
subdirectory has different package requirements and has been set up
to use autoconf, automake, libtool, m4, etc..
Wait. If it's just about different package requirements, then you don't
need to mess with toplevel at all. All --with-* and
--enable-*/--disable-* flags are passed down to each sub configure
script. Each of the configure scripts can just choose to adhere to the
flags it knows, and ignore the rest, no?

Cheers,
Ralf
Jim Galarowicz
2011-03-29 14:30:27 UTC
Permalink
Hi Ralf,

Thanks for the reply!
Post by Ralf Wildenhues
Hello Jim,
Post by Jim Galarowicz
I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements.
Well, you can just write code yourself that calls the sub configure
scripts with the arguments you intend for it. Basically your own
version of AC_CONFIG_SUBDIRS, if you like.
GCC does this in its own tree (except the code is partly in the
makefile, not only the toplevel configure script).
For simple things, it often suffices to adjust $ac_configure_args during
configure (beware of the eval quoting though!).
However, you haven't written what kind of adjustments you need at all,
so it's not clear how to help more.
Post by Jim Galarowicz
My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet. Each
subdirectory has different package requirements and has been set up
to use autoconf, automake, libtool, m4, etc..
Wait. If it's just about different package requirements, then you don't
need to mess with toplevel at all. All --with-* and
--enable-*/--disable-* flags are passed down to each sub configure
script. Each of the configure scripts can just choose to adhere to the
flags it knows, and ignore the rest, no?
I'll still need a configure at the top level in order to pass down the
superset of all the options that the subdirectories will need, correct?
The top-level would have to have all the configuration settings that
each of the lower level subdirectories would need to recognize and then
each subdirectory configure can apply what it recognizes.

I will try this approach.

Thanks,
Jim G
Post by Ralf Wildenhues
Cheers,
Ralf
Ralf Wildenhues
2011-03-31 05:37:14 UTC
Permalink
Post by Jim Galarowicz
Post by Ralf Wildenhues
Post by Jim Galarowicz
I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements.
[...]
Post by Jim Galarowicz
Post by Ralf Wildenhues
Post by Jim Galarowicz
My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet. Each
subdirectory has different package requirements and has been set up
to use autoconf, automake, libtool, m4, etc..
Wait. If it's just about different package requirements, then you don't
need to mess with toplevel at all. All --with-* and
--enable-*/--disable-* flags are passed down to each sub configure
script. Each of the configure scripts can just choose to adhere to the
flags it knows, and ignore the rest, no?
I'll still need a configure at the top level in order to pass down
the superset of all the options that the subdirectories will need,
correct?
Correct. But since a configure script passes all options from the user
down, that's trivial to fulfill, as long as option semantics do not
contradict each other. Of course, when they do, or when you want to
pass a different set of options to each sub configure, the TODO items
discussed elsewhere in this thread apply.
Post by Jim Galarowicz
The top-level would have to have all the configuration
settings that each of the lower level subdirectories would need to
recognize
No.
Post by Jim Galarowicz
and then each subdirectory configure can apply what it recognizes.
Yes.

Cheers,
Ralf
NightStrike
2011-03-29 16:23:51 UTC
Permalink
Post by Ralf Wildenhues
Hello Jim,
Post by Jim Galarowicz
I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements.
Well, you can just write code yourself that calls the sub configure
scripts with the arguments you intend for it.  Basically your own
version of AC_CONFIG_SUBDIRS, if you like.
GCC does this in its own tree (except the code is partly in the
makefile, not only the toplevel configure script).
For simple things, it often suffices to adjust $ac_configure_args during
configure (beware of the eval quoting though!).
However, you haven't written what kind of adjustments you need at all,
so it's not clear how to help more.
Post by Jim Galarowicz
My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet.  Each
subdirectory has different package requirements and has been set up
to use autoconf, automake, libtool, m4, etc..
Wait.  If it's just about different package requirements, then you don't
need to mess with toplevel at all.  All --with-* and
--enable-*/--disable-* flags are passed down to each sub configure
script.  Each of the configure scripts can just choose to adhere to the
flags it knows, and ignore the rest, no?
What if options conflict? For instance, say you have a sub package
that should be enable-shared disable-static, and another that should
be enable-static and disable-shared? Or one that needs --with-foo and
one that needs --without-foo? Or any other type of conflicting
options?
Stefano Lattarini
2011-03-29 16:39:07 UTC
Permalink
Hello autoconfers. Just my 2 cents about the issue ...
Post by NightStrike
Post by Ralf Wildenhues
Hello Jim,
Post by Jim Galarowicz
I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements.
Well, you can just write code yourself that calls the sub configure
scripts with the arguments you intend for it. Basically your own
version of AC_CONFIG_SUBDIRS, if you like.
GCC does this in its own tree (except the code is partly in the
makefile, not only the toplevel configure script).
For simple things, it often suffices to adjust $ac_configure_args during
configure (beware of the eval quoting though!).
However, you haven't written what kind of adjustments you need at all,
so it's not clear how to help more.
Post by Jim Galarowicz
My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet. Each
subdirectory has different package requirements and has been set up
to use autoconf, automake, libtool, m4, etc..
Wait. If it's just about different package requirements, then you don't
need to mess with toplevel at all. All --with-* and
--enable-*/--disable-* flags are passed down to each sub configure
script. Each of the configure scripts can just choose to adhere to the
flags it knows, and ignore the rest, no?
What if options conflict? For instance, say you have a sub package
that should be enable-shared disable-static, and another that should
be enable-static and disable-shared? Or one that needs --with-foo and
one that needs --without-foo? Or any other type of conflicting
options?
Do you think it would be viable/useful to enahnace AC_CONFIG_SUBDIRS (or
write a brand new macro) to allow the "parent" configure script to pass
different options to different "sub" configure scripts? I know one can
use the `configure.gnu' hack, but that does not seem clear or natural as
using e.g.:
AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
AC_CONFIG_SUBDIRS([bar], [--without-zardoz])

Regards,
Stefano
Jim Galarowicz
2011-03-29 16:57:34 UTC
Permalink
Hi,

Thanks for all the great responses! I appreciate them. This would seem
to be the ideal solution for my issue.

Jim G.
Post by Stefano Lattarini
AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
AC_CONFIG_SUBDIRS([bar], [--without-zardoz])
I think this might be a wonderful idea. I haven't looked at it much,
but it has potential. We might well need/use something like this for NTP.
I can't easily look right now, though.
It helps a lot if the choice of options will change based on "parent"
choices.
H
Ralf Corsepius
2011-03-29 17:24:07 UTC
Permalink
Post by Stefano Lattarini
Hello autoconfers. Just my 2 cents about the issue ...
Do you think it would be viable/useful to enahnace AC_CONFIG_SUBDIRS (or
write a brand new macro) to allow the "parent" configure script to pass
different options to different "sub" configure scripts? I know one can
use the `configure.gnu' hack, but that does not seem clear or natural as
AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
AC_CONFIG_SUBDIRS([bar], [--without-zardoz])
It's a step into the right direction. It is useful in cases when you
only want to append arguments (which often applies).

However, in general, you will want to process a configure script
arguments and to compose the arguments to pass to sub-configure scripts.

Also to be taken into account in such a context would be autoconf's
"precious vars" and config.caches (They both only work if a
sub-configure's precious vars and config.cache'ed vars's notion matches).

When generalizing more, there are cases a user wants to create build
subdirs dynamically. Classical use case for this would be a
cross-compiled package suite containing "build"/"host" and (several)
target compiled subdirs. Another use-case would be users wanting to
compile the same subdir multiple times.

Ralf
Harlan Stenn
2011-03-29 16:44:32 UTC
Permalink
Post by Stefano Lattarini
AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
AC_CONFIG_SUBDIRS([bar], [--without-zardoz])
I think this might be a wonderful idea. I haven't looked at it much,
but it has potential. We might well need/use something like this for NTP.

I can't easily look right now, though.

It helps a lot if the choice of options will change based on "parent"
choices.

H
Harlan Stenn
2011-04-01 07:04:09 UTC
Permalink
Post by Stefano Lattarini
AC_CONFIG_SUBDIRS([foo], [--with-zardoz])
And I now have a case where I think I want to pass in a CPPFLAGS entry
to a subpackage, based on "stuff" that the "parent" configure knows.

So I'm thinking about:

AC_CONFIG_SUBDIRS([foo], [--with-zardoz CPPFLAGS=-Isomething])

Not sure if this is a great idea or not, but the only other alternative
I can think of is to modify the configure.ac in the subpackage, and I
would rather not do that as it creates "extra work" when I go to upgrade
the subpackage.

H
Ralf Wildenhues
2011-04-01 07:13:33 UTC
Permalink
Post by Harlan Stenn
Not sure if this is a great idea or not, but the only other alternative
I can think of is to modify the configure.ac in the subpackage, and I
would rather not do that as it creates "extra work" when I go to upgrade
the subpackage.
But you are aware of the configure.gnu "trick"? See info Autoconf
Subdirectories for the semantics.

The trick is: you adjust the flags in subpkg/configure.gnu, then call
subpkg/configure with them. The subpkg/configure.gnu file might
actually belong to the toplevel package. A hack, but fairly easy.

I like the idea of a more flexible AC_CONFIG_SUBDIRS replacement, but
the suggested API does not really look appropriate yet, with all the
finer details of precious variables, (non-)shared config.cache handling
and so on still needing sane and precise semantics.

Cheers,
Ralf
Harlan Stenn
2011-04-01 07:41:33 UTC
Permalink
Post by Ralf Wildenhues
Post by Harlan Stenn
Not sure if this is a great idea or not, but the only other alternative
I can think of is to modify the configure.ac in the subpackage, and I
would rather not do that as it creates "extra work" when I go to upgrade
the subpackage.
But you are aware of the configure.gnu "trick"? See info Autoconf
Subdirectories for the semantics.
I'll check that out, thanks.
Post by Ralf Wildenhues
The trick is: you adjust the flags in subpkg/configure.gnu, then call
subpkg/configure with them. The subpkg/configure.gnu file might
actually belong to the toplevel package. A hack, but fairly easy.
In the srcdir? How would that work for distcheck, which, as I recall,
uses a read-only srcdir to simulate building from read-only media.

But I'll read up on it anyway, to see if configure.gnu can be put in the
build-dir before running srcdir/configure .
Post by Ralf Wildenhues
I like the idea of a more flexible AC_CONFIG_SUBDIRS replacement, but
the suggested API does not really look appropriate yet, with all the
finer details of precious variables, (non-)shared config.cache handling
and so on still needing sane and precise semantics.
Understood and agreed - thanks!

H
Ralf Wildenhues
2011-04-01 07:47:02 UTC
Permalink
Post by Harlan Stenn
Post by Ralf Wildenhues
The trick is: you adjust the flags in subpkg/configure.gnu, then call
subpkg/configure with them. The subpkg/configure.gnu file might
actually belong to the toplevel package. A hack, but fairly easy.
In the srcdir? How would that work for distcheck, which, as I recall,
uses a read-only srcdir to simulate building from read-only media.
Well, put it in the distribution:
EXTRA_DIST = subpkg/configure.gnu
Post by Harlan Stenn
But I'll read up on it anyway, to see if configure.gnu can be put in the
build-dir before running srcdir/configure .
Yep.

Cheers,
Ralf
Harlan Stenn
2011-04-01 08:06:14 UTC
Permalink
Post by Ralf Wildenhues
Post by Harlan Stenn
Post by Ralf Wildenhues
The trick is: you adjust the flags in subpkg/configure.gnu, then call
subpkg/configure with them. The subpkg/configure.gnu file might
actually belong to the toplevel package. A hack, but fairly easy.
In the srcdir? How would that work for distcheck, which, as I recall,
uses a read-only srcdir to simulate building from read-only media.
EXTRA_DIST = subpkg/configure.gnu
I'll think about that.

The use-case I have is I'm bootstrapping a package that has a bunch of
sub-packages. The bootstrap process will "temporarily" install things
in a bootstrap directory, so I need to be able to pass in the -I
(definitely) and -L (maybe, not that far along yet) args for the "rest"
of the bootstrap tools.

Since that "parent" configure uses --prefix= to set this bootstrap
installation directory, I might be able to have configure.gnu say
"configure ... CPPFLAGS='${prefix}/include'" (more or less) and then I
would not need to worry about customizing the location of the include
files on each "run".
Post by Ralf Wildenhues
Post by Harlan Stenn
But I'll read up on it anyway, to see if configure.gnu can be put in the
build-dir before running srcdir/configure .
Yep.
This is a work-in-process, and I am whacking a path thru the jungle...
Sometimes I even have to backtrack and try a different route.

But it's kinda fun.

H
Christian Rössel
2011-04-01 14:56:28 UTC
Permalink
Hi Jim, hi Ralf, hi all,
Post by Ralf Wildenhues
Hello Jim,
Post by Jim Galarowicz
I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements.
Well, you can just write code yourself that calls the sub configure
scripts with the arguments you intend for it. Basically your own
version of AC_CONFIG_SUBDIRS, if you like.
I wrote a macro (AC_CONFIG_SUBDIR_CUSTOM, patch applied) to pass
different arguments to different sub-configures. Like AC_CONFIG_SUBDIRS
it preserves
* --cache-file
* --silent
and passes always
* --srcdir
* --prefix
* --disable-option-checking

AC_CONFIG_SUBDIR_CUSTOM takes at least two arguments, the directory
where the sub-configure resides and the additional arguments to be
passed to this specific sub-configure. An optional third parameter
controls if the sub-configure is recognized by a configure --help=recursive.
Post by Ralf Wildenhues
GCC does this in its own tree (except the code is partly in the
makefile, not only the toplevel configure script).
For simple things, it often suffices to adjust $ac_configure_args during
configure (beware of the eval quoting though!).
However, you haven't written what kind of adjustments you need at all,
so it's not clear how to help more.
Post by Jim Galarowicz
My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet. Each
subdirectory has different package requirements and has been set up
to use autoconf, automake, libtool, m4, etc..
Jim, you would use it like this in your toplevel configure.ac:

AC_CONFIG_SUBDIR_CUSTOM([libcbtf], [$arguments_to_libcbtf])
AC_CONFIG_SUBDIR_CUSTOM([libcbtf-xml], [$arguments_to_libcbtf-xml])
AC_CONFIG_SUBDIR_CUSTOM([libcbtf-mrnet], [$arguments_to_libcbtf-mrnet])

Cheers,
Christian

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
Jim Galarowicz
2011-04-05 17:55:54 UTC
Permalink
Hi Christian, all,

I've applied the patch to autoconf-2.65 and it works wonderfully!!
Thanks so much to you and all who have participated in this discussion
and action.

Since the email thread started we have two more subdirectories. My
configure.ac file now has these 5 AC_CONFIG_SUBDIR_CUSTOM lines in it:

AC_CONFIG_SUBDIR_CUSTOM([libcbtf], [--prefix=$CBTF_PREFIX
--with-boost=$CBTF_BOOST_PREFIX --with-boost-libdir=$CBTF_BOOST_PREFIX_LIB])

AC_CONFIG_SUBDIR_CUSTOM([libcbtf-xml], [--prefix=$CBTF_PREFIX
--with-cbtf=$CBTF_PREFIX --with-libxerces-c-prefix=$CBTF_XERCESC_PREFIX])

AC_CONFIG_SUBDIR_CUSTOM([libcbtf-mrnet], [--prefix=$CBTF_PREFIX
--with-cbtf=$CBTF_PREFIX --with-cbtf-xml=$CBTF_PREFIX
--with-libxerces-c-prefix=$CBTF_XERCESC_PREFIX
--with-mrnet=$CBTF_MRNET_PREFIX])

AC_CONFIG_SUBDIR_CUSTOM([messages], [--prefix=$CBTF_PREFIX
--with-cbtf=$CBTF_PREFIX --with-mrnet=$CBTF_MRNET_PREFIX
--with-libxerces-c-prefix=$CBTF_XERCESC_PREFIX
--with-cbtf-xml=$CBTF_PREFIX --with-cbtf-mrnet=$CBTF_PREFIX])

AC_CONFIG_SUBDIR_CUSTOM([services], [ --prefix=$CBTF_PREFIX
--with-mrnet=$CBTF_MRNET_PREFIX --with-cbtf-messages=$CBTF_PREFIX
--with-libmonitor=$CBTF_ROOT --with-libunwind=$CBTF_ROOT
--with-papi=$CBTF_ROOT --with-tls=implicit --with-binutils=$CBTF_ROOT
--with-cbtf=$CBTF_PREFIX])

I'm able to bootstrap, configure --prefix=$CBTF_PREFIX at the top level
and have each of the subdirectories configure with their respective
configure lines. Very cool indeed!

Thanks again!

Will this make it into the main line release?

Jim G.
Post by Christian Rössel
Hi Jim, hi Ralf, hi all,
Post by Ralf Wildenhues
Hello Jim,
Post by Jim Galarowicz
I was wondering if anyone can point me to any information on how to
configure from a top-level directory multiple sub-directories with
different configure requirements.
Well, you can just write code yourself that calls the sub configure
scripts with the arguments you intend for it. Basically your own
version of AC_CONFIG_SUBDIRS, if you like.
I wrote a macro (AC_CONFIG_SUBDIR_CUSTOM, patch applied) to pass
different arguments to different sub-configures. Like AC_CONFIG_SUBDIRS
it preserves
* --cache-file
* --silent
and passes always
* --srcdir
* --prefix
* --disable-option-checking
AC_CONFIG_SUBDIR_CUSTOM takes at least two arguments, the directory
where the sub-configure resides and the additional arguments to be
passed to this specific sub-configure. An optional third parameter
controls if the sub-configure is recognized by a configure --help=recursive.
Post by Ralf Wildenhues
GCC does this in its own tree (except the code is partly in the
makefile, not only the toplevel configure script).
For simple things, it often suffices to adjust $ac_configure_args during
configure (beware of the eval quoting though!).
However, you haven't written what kind of adjustments you need at all,
so it's not clear how to help more.
Post by Jim Galarowicz
My subdirectories are: libcbtf, libcbtf-xml, libcbtf-mrnet. Each
subdirectory has different package requirements and has been set up
to use autoconf, automake, libtool, m4, etc..
AC_CONFIG_SUBDIR_CUSTOM([libcbtf], [$arguments_to_libcbtf])
AC_CONFIG_SUBDIR_CUSTOM([libcbtf-xml], [$arguments_to_libcbtf-xml])
AC_CONFIG_SUBDIR_CUSTOM([libcbtf-mrnet], [$arguments_to_libcbtf-mrnet])
Cheers,
Christian
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Besuchen Sie uns auf unserem neuen Webauftritt unterwww.fz-juelich.de
AC_CONFIG_SUBDIR_CUSTOM.patch
diff --git a/lib/autoconf/status.m4 b/lib/autoconf/status.m4
index 46a0341..d028ede 100644
--- a/lib/autoconf/status.m4
+++ b/lib/autoconf/status.m4
@@ -191,7 +191,7 @@ m4_define([_AC_CONFIG_DEPENDENCY_DEFAULT],
# _AC_CONFIG_UNIQUE(MODE, DEST)
# -----------------------------
-# MODE is `FILES', `HEADERS', `LINKS', `COMMANDS', or `SUBDIRS'.
+# MODE is `FILES', `HEADERS', `LINKS', `COMMANDS', `SUBDIRS' or CONFIG_SUBDIR_CUSTOM.
#
# Verify that there is no double definition of an output file.
#
@@ -1097,7 +1097,7 @@ m4_define([AC_OUTPUT_COMMANDS_POST])
AC_DEFUN([AC_CONFIG_SUBDIRS],
[AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])]dnl
[AC_REQUIRE([AC_DISABLE_OPTION_CHECKING])]dnl
-[m4_map_args_w([$1], [_AC_CONFIG_UNIQUE([SUBDIRS],
+[m4_map_args_w([$1], [_AC_CONFIG_UNIQUE([SUBDIRS or CONFIG_SUBDIR_CUSTOM],
_AC_CONFIG_COMPUTE_DEST(], [))])]dnl
[m4_append([_AC_LIST_SUBDIRS], [$1], [
])]dnl
@@ -1106,6 +1106,41 @@ AC_DEFUN([AC_CONFIG_SUBDIRS],
[AC_SUBST([subdirs], ["$subdirs m4_normalize([$1])"])])
+# AC_CONFIG_SUBDIR_CUSTOM(DIR, ARGUMENTS [, DISABLE_HELP_RECURSIVE])
+# ------------------------------------------------------------------
+# Build a list custom_subdirs of tuples (DIR, ARGUMENTS) where DIR is
+# unique in _AC_LIST_CUSTOM_SUBDIRS and _AC_LIST_SUBDIRS. This list is used in
+# _AC_OUTPUT_SUBDIRS to invoke nested configures in directory DIR with
+# arguments ARGUMENTS. The arguments are modified as in the AC_CONFIG_SUBDIRS
+# case, see _AC_SUB_CONFIGURE_ARGS. If the third argument
+# DISABLE_HELP_RECURSIVE is given, configure --help=recursive will omit DIR.
+AC_DEFUN([AC_CONFIG_SUBDIR_CUSTOM],
+[AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])]dnl
+[AC_REQUIRE([AC_DISABLE_OPTION_CHECKING])]dnl
+[m4_foreach_w([_AC_Sub], [$1],
+ [_AC_CONFIG_UNIQUE([SUBDIRS or CONFIG_SUBDIR_CUSTOM],
+ m4_bpatsubst(m4_defn([_AC_Sub]), [:.*]))])]dnl
+
+# build a list of (directory,arguments) tuples that will be processed in _AC_OUTPUT_SUBDIRS
+[if test -z "$custom_subdirs"; then
+ custom_subdirs="custom_sub_configure_dir=\"m4_normalize([$1])\";custom_sub_configure_args=\"m4_normalize([$2])\""
+else
+ custom_subdirs="$custom_subdirs|custom_sub_configure_dir=\"m4_normalize([$1])\";custom_sub_configure_args=\"m4_normalize([$2])\""
+fi]
+
+# per default, enable --help=recursive in directory $1.
+[m4_ifval([$3],
+ [],
+ [m4_append([_AC_LIST_SUBDIRS], [$1], [
+])dnl
+])]dnl
+[AS_LITERAL_IF([$1], [],
+ [AC_DIAGNOSE([syntax], [$0: you should use literals])])]dnl
+[AC_SUBST([subdirs_custom], ["$subdirs_custom m4_normalize([$1])"])]dnl
+)
+# AC_CONFIG_SUBDIR_CUSTOM
+
+
# _AC_OUTPUT_SUBDIRS
# ------------------
# This is a subroutine of AC_OUTPUT, but it does not go into
@@ -1116,12 +1151,50 @@ m4_define([_AC_OUTPUT_SUBDIRS],
# CONFIG_SUBDIRS section.
#
if test "$no_recursion" != yes; then
+ ac_popdir=`pwd`
+
+ # call configures in list $custom_subdirs with directory-specific arguments.
+ OIFS=$IFS
+ IFS='|'
+ list=$custom_subdirs
+ for dir_and_args in $list; do
+ IFS=$OIFS
+ eval $dir_and_args
+ if test "x$custom_sub_configure_dir" = x; then continue; fi
+ ac_custom_sub_configure_args=
+ _AC_SUB_CONFIGURE_ARGS([$custom_sub_configure_args],
+ [ac_custom_sub_configure_args])
+ _AC_SUB_CONFIGURE([$custom_sub_configure_dir],
+ [$ac_custom_sub_configure_args])
+ cd "$ac_popdir"
+ IFS='|'
+ done
+ IFS=$OIFS
+
+ # call configures in $subdirs with fixed arguments.
+ ac_sub_configure_args=
+ _AC_SUB_CONFIGURE_ARGS([$ac_configure_args],
+ [ac_sub_configure_args])
+ for ac_dir in : $subdirs; do test "x$ac_dir" = x:&& continue
+ echo "ac_dir(inside): $ac_dir"
+ _AC_SUB_CONFIGURE([$ac_dir],
+ [$ac_sub_configure_args])
+ cd "$ac_popdir"
+ done
+fi
+])# _AC_OUTPUT_SUBDIRS
+
+# _AC_SUB_CONFIGURE_ARGS(ARGUMENTS_IN, ARGUMENTS_OUT)
+# ---------------------------------------------------
+# Create ARGUMENTS_OUT from ARGUMENTS_IN for use in nested configure calls.
+m4_define([_AC_SUB_CONFIGURE_ARGS],
+[
# Remove --cache-file, --srcdir, and --disable-option-checking arguments
# so they do not pile up.
ac_sub_configure_args=
ac_prev=
- eval "set x $ac_configure_args"
+ eval "set x $1"
shift
for ac_arg
do
@@ -1153,7 +1226,7 @@ if test "$no_recursion" != yes; then
case $ac_arg in
*\'*) ac_arg=`AS_ECHO(["$ac_arg"]) | sed "s/'/'\\\\\\\\''/g"` ;;
esac
- AS_VAR_APPEND([ac_sub_configure_args], [" '$ac_arg'"]) ;;
+ AS_VAR_APPEND([$2], [" '$ac_arg'"]) ;;
esac
done
@@ -1163,66 +1236,68 @@ if test "$no_recursion" != yes; then
case $ac_arg in
*\'*) ac_arg=`AS_ECHO(["$ac_arg"]) | sed "s/'/'\\\\\\\\''/g"` ;;
esac
- ac_sub_configure_args="'$ac_arg' $ac_sub_configure_args"
+ $2="'$ac_arg' $$2"
# Pass --silent
if test "$silent" = yes; then
- ac_sub_configure_args="--silent $ac_sub_configure_args"
+ $2="--silent $$2"
fi
# Always prepend --disable-option-checking to silence warnings, since
# different subdirs can have different --enable and --with options.
- ac_sub_configure_args="--disable-option-checking $ac_sub_configure_args"
+ $2="--disable-option-checking $$2"
+])# _AC_SUB_CONFIGURE_ARGS
- ac_popdir=`pwd`
- for ac_dir in : $subdirs; do test "x$ac_dir" = x:&& continue
- # Do not complain, so a configure script can configure whichever
- # parts of a large source tree are present.
- test -d "$srcdir/$ac_dir" || continue
-
- ac_msg="=== configuring in $ac_dir (`pwd`/$ac_dir)"
- _AS_ECHO_LOG([$ac_msg])
- _AS_ECHO([$ac_msg])
- AS_MKDIR_P(["$ac_dir"])
- _AC_SRCDIRS(["$ac_dir"])
-
- cd "$ac_dir"
-
- # Check for guested configure; otherwise get Cygnus style configure.
- if test -f "$ac_srcdir/configure.gnu"; then
- ac_sub_configure=$ac_srcdir/configure.gnu
- elif test -f "$ac_srcdir/configure"; then
- ac_sub_configure=$ac_srcdir/configure
- elif test -f "$ac_srcdir/configure.in"; then
- # This should be Cygnus configure.
- ac_sub_configure=$ac_aux_dir/configure
- else
- AC_MSG_WARN([no configuration information is in $ac_dir])
- ac_sub_configure=
- fi
-
- # The recursion is here.
- if test -n "$ac_sub_configure"; then
- # Make the cache file name correct relative to the subdirectory.
- case $cache_file in
- [[\\/]]* | ?:[[\\/]]* ) ac_sub_cache_file=$cache_file ;;
- *) # Relative name.
- ac_sub_cache_file=$ac_top_build_prefix$cache_file ;;
- esac
-
- AC_MSG_NOTICE([running $SHELL $ac_sub_configure $ac_sub_configure_args --cache-file=$ac_sub_cache_file --srcdir=$ac_srcdir])
- # The eval makes quoting arguments work.
- eval "\$SHELL \"\$ac_sub_configure\" $ac_sub_configure_args \
- --cache-file=\"\$ac_sub_cache_file\" --srcdir=\"\$ac_srcdir\"" ||
- AC_MSG_ERROR([$ac_sub_configure failed for $ac_dir])
- fi
+# _AC_SUB_CONFIGURE(DIR, ARGUMENTS)
+# ---------------------------------
+# Call nested configure in DIR with arguments ARGUMENTS.
+m4_define([_AC_SUB_CONFIGURE],
+[
+ sub_configure_dir=$1
+ sub_configure_args=$2
+
+ # Do not complain, so a configure script can configure whichever
+ # parts of a large source tree are present.
+ test -d "$srcdir/$sub_configure_dir" || continue
+
+ ac_msg="=== configuring in $sub_configure_dir (`pwd`/$sub_configure_dir)"
+ _AS_ECHO_LOG([$ac_msg])
+ _AS_ECHO([$ac_msg])
+ AS_MKDIR_P(["$sub_configure_dir"])
+ _AC_SRCDIRS(["$sub_configure_dir"])
+
+ cd "$sub_configure_dir"
+
+ # Check for guested configure; otherwise get Cygnus style configure.
+ if test -f "$ac_srcdir/configure.gnu"; then
+ ac_sub_configure=$ac_srcdir/configure.gnu
+ elif test -f "$ac_srcdir/configure"; then
+ ac_sub_configure=$ac_srcdir/configure
+ elif test -f "$ac_srcdir/configure.in"; then
+ # This should be Cygnus configure.
+ ac_sub_configure=$ac_aux_dir/configure
+ else
+ AC_MSG_WARN([no configuration information is in $sub_configure_dir])
+ ac_sub_configure=
+ fi
- cd "$ac_popdir"
- done
-fi
-])# _AC_OUTPUT_SUBDIRS
+ # The recursion is here.
+ if test -n "$ac_sub_configure"; then
+ # Make the cache file name correct relative to the subdirectory.
+ case $cache_file in
+ [[\\/]]* | ?:[[\\/]]* ) ac_sub_cache_file=$cache_file ;;
+ *) # Relative name.
+ ac_sub_cache_file=$ac_top_build_prefix$cache_file ;;
+ esac
+ AC_MSG_NOTICE([running $SHELL $ac_sub_configure $sub_configure_args --cache-file=$ac_sub_cache_file --srcdir=$ac_srcdir])
+ # The eval makes quoting arguments work.
+ eval "\$SHELL \"\$ac_sub_configure\" $sub_configure_args \
+ --cache-file=\"\$ac_sub_cache_file\" --srcdir=\"\$ac_srcdir\"" ||
+ AC_MSG_ERROR([$ac_sub_configure failed for $sub_configure_dir])
+ fi
+])# _AC_SUB_CONFIGURE
@@ -1304,7 +1379,10 @@ if test "$no_create" != yes; then
$ac_cs_success || AS_EXIT([1])
fi
dnl config.status should not do recursion.
-AC_PROVIDE_IFELSE([AC_CONFIG_SUBDIRS], [_AC_OUTPUT_SUBDIRS()])dnl
+AC_PROVIDE_IFELSE([AC_CONFIG_SUBDIRS],
+ [_AC_OUTPUT_SUBDIRS()],
+ [AC_PROVIDE_IFELSE([AC_CONFIG_SUBDIR_CUSTOM],
+ [_AC_OUTPUT_SUBDIRS()])])dnl
if test -n "$ac_unrecognized_opts"&& test "$enable_option_checking" != no; then
AC_MSG_WARN([unrecognized options: $ac_unrecognized_opts])
fi
_______________________________________________
Autoconf mailing list
http://lists.gnu.org/mailman/listinfo/autoconf
Jim Galarowicz
2011-05-05 15:38:52 UTC
Permalink
Hi all,

I'm writing to see if the patch that Christian developed will become a part of the mainline autoconf.

My team members do not want to use a non-mainstream method to configure. Is there is a possibility of this becoming mainstream?

Thanks again! This does work great with no side effects that I can tell.

Jim G
Christian Rössel
2011-05-06 07:30:05 UTC
Permalink
Jim,
Post by Jim Galarowicz
Hi all,
I'm writing to see if the patch that Christian developed will become a part of the mainline autoconf.
My team members do not want to use a non-mainstream method to configure. Is there is a possibility of this becoming mainstream?
Thanks again! This does work great with no side effects that I can tell.
Jim G
thanks for the positive feedback!

At the moment I'm in the process of doing copyright assignments with the
FSF, which is a prerequisite that my patch may become mainstream. This
may take some time. I will get back to this thread as soon as this is done.

Cheers,
Christian

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
Continue reading on narkive:
Loading...