On Wed, Oct 30, 2002 at 12:12:20PM -0500, Eric Siegerman wrote: > On Tue, Oct 29, 2002 at 07:16:45PM -0500, Steve M. Robbins wrote: > > On Tue, Oct 29, 2002 at 01:52:20PM -0500, Stefan Seefeld wrote: > > > AC_CONFIG_SUBDIRS(dirs, [action-if-succeeds], [action-if-fails]) > > > > > > is exactly what I had in mind. > > > > If someone gets ambitious, it would be also useful to have > > AC_CXX([action-if-succeeds],[action-if-fails]) to deal with > > "compile-if-you-have-a-C++-compiler" bits of a package. > > Assuming the AC_CONFIG_SUBDIRS enhancement is made, > "compile-if-you-have-a-C++-compiler" should be implemented in > terms of it, by putting the C++ code in a subpackage.
An interesting possibility that I hadn't considered. The objection to this that some will have is that to require an extra configure script and all that setup in a subdirectory is a heavy burden for e.g. a single program or two that uses C++ in a large package. To put this into a question: why should supporting optional C++ parts of a package be so much more trouble than supporting an optional 3rd party library? > This will > avoid a lot of rarely-used "[action-if-succeeds], > [action-if-fails]" goo spreading throughout the API. > > IMHO, adding such goo to AC_CONFIG_SUBDIRS is justified precisely > because using subdirectories is a common and obvious way to > factor out optional subcomponents of a package. It's a single > change that's sufficient to handle a wide set of similar cases. I might be misremembering, but I seem to recall someone mooting the possibility of wrapping macros like AC_CXX or AC_CONFIG_SUBDIRS inside some (m4?) code that temporarily turns a fatal error into a warning. I think it did something like redefine AC_MSG_ERROR into AC_MSG_WARN. Does this ring any bells for someone? -Steve
