> > A probably nicer alternative would be to have a separate > > configure(.in) in the wilytools together with an AC_CONFIG_SUBDIRS > > in wily's configure(.in) to let it run the wilytools configure > > if it's there. > > Sorry, but why is this nicer? Extending the top-level configure and > Makefiles is probably The Right Thing, as recursive make is bad. Using AC_CONFIG_SUBDIRS is nicer, because extending the top-level configure gets messy if the subdir that you want to add is optional, because then things have to be done conditionally (depending on the presence or absence of the optional component), and then you quickly end up on your own, because (at least in my experience) not all things (macros) in the autoconf world have the extreme flexibility you would need. However, AC_CONFIG_SUBDIRS does have this flexibility, it is (looks like?) made for it: it lets you specify optional components in your toplevel configure, and it will configure them if they are there, but also be happy if they are not there. To give an example: in the configure.in AC_OUTPUT macro you have to specify the Makefiles that should be generated for the optional package, but these should be generated conditionally. AFAIK the AC_OUTPUT simply expects to be able to generate all the things that it is said to do, so it will not be happy if the directory which is supposed to contain the Makefile(s) for the optional package simply is not there. I don't know whether you can use variables as arguments to AC_OUTPUT (if I ever tried it's too long ago for me to recall). W.r.t. recursive make: as soon as you have multiple directories, you end up with recursive make in one way or another, I think. Especially if you want to be able to make in each of the directories individually, but also want to be able to make the whole package with a single `make' invocation in the top-level directory. In my wily source directory (version 0.13.41) I see recursive make. Axel.