On Wed, Dec 06, 2006 at 08:06:54PM +0100, Ralf Wildenhues wrote: > Hello Bob, > > * Bob Rossi wrote on Wed, Dec 06, 2006 at 03:40:00PM CET: > > > > When you run the top-level configure script, it determines what libraries you > > need to build the project, and then downloads the .tar.gz dependency, untars > > it, and configures it. Currently I ./configure the sub projects manually by > > calling the sub projects ./configure directly. However, using AC_CONFIG_SUBDIRS > > might be better, because I think it'll pass down the top-level configure options > > to the subproject. > > Right. It assumes some things though: for example, that you may want to > share the cache file between the two configure runs. This is not > practical, for example, if one but not both packages are to be cross > compiled (e.g., because you need a compiler for both $host and $build). > > > I'm wondering if there is a way to get AC_CONFIG_SUBDIRS to work, even > > though the configure script or sub directory isn't available until > > ./configure is run and it determines what libraries to download. > > This should already work out of the box. If the file $sub/configure is > present at the time it should be run (at the end of configuring), then > it will be run. OK, something must be wrong with my setup then. I'll look into it. > > I'm wondering how options are passed down through AC_CONFIG_SUBDIRS from > > the top-level Makefile. Can you tweak the options for each sub project? > > No. This is currently one of the biggest limitations of this macro. > I'd be happy if we could come up with another macro for sub-configure > scripts that would allow for more freedom. Primary issues are: > - What and how can we allow the user to specify what is passed/mangled/ > not passed? This is trickier than it seems: package authors typically > cannot know which option an end-user would like to be passed down. > - When should cache file sharing be turned off? > > Some other technical details come to mind as well. > > This could help eliminate the number of mostly-buggy hand-written bits > that several package use, in the long term. > > If you embark upon writing a private macro for yourself, please start > from a recent copy of Autoconf's and modify that. Older versions have > had more quoting quirks. OK, I don't have time to do this now. However I am interested in the functionality. Maybe sometime in the future ... Thanks, Bob Rossi _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
