On 28 Oct 2002, Akim Demaille wrote:
> What is the feature you (Jeff) lack? Why would it be normal to fail?
> What can't you have the sub configure exit 0 in case of
> what-is-not-that-much-of-a-failure?
>
> People have used
>
> if test -d foo; then
> AC_CONFIG_SUBDIRS(foo)
> fi
>
> successfully until now (as suggested by Earnie).
When you us AC_CONFIG_SUBDIRS, foo/configure is run *after* the main
configure script completes (I don't know the exact mojo, but its
definitely run either after or at the end of my top-level configure.ac's
AC_OUTPUT). Sorry -- I had forgotten about this, or I would have
mentioned it in a previous post. I remembered it when I wrote some quick
test examples to be able to reply intelligently. :-)
So there's no chance for the top-level configure.ac to analyze and react
if foo/configure fails. Also, if foo/configure fails but still does an
"exit 0" (and therefore the overall configure succeeds), then the
top-level package still thinks that foo is compilable/installable.
Hence, foo's configure.ac has extra work to do to ensure that the entire
package is able to be compiled/installed:
- if foo/configure succeeds, setup the foo package as normal
- if foo/configure fails, setup the foo package so that "make all" and
"make install" essentially pass-through and do nothing. This
essentially means adding a whole level of indirection to Makefile.am
files.
It is much more desirable to allow the top-level configure.ac to determine
that foo/configure failed and then not add "foo" to SUBDIRS so that
various make targets never traverse into "foo" in the first place (since
it is possible/likely that no Makefiles have been generated in the foo
tree).
The big workaround that I did was mainly for 2 reasons:
1. Allow sub-configure scripts to be run *during* the execution of the
top-level configure.ac (and therefore the top-level configure.ac can check
for success or failure).
2. Allow sub-configure scripts to return != 0 status and fail cleanly
without having to configure themselves in a "pass through" mode.
I hope that makes sense. :-)
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Research Associate, Open Systems Lab, Indiana University
{+} http://www.osl.iu.edu/
