On Monday, May 08, 2006 Ralf Wildenhues wrote: <quoted out of order>
> If you're going to merge the Makefile.am's, or include one > into the other, be sure to do the configure.ac merge first. Your post just got this to sink in for me. I was trying to keep the configure.ac's separate since it felt better to have the autoconf logic together with the modules that needed it instead of in one massive configure.ac file. Is there a way to include configure.ac fragments? > Maybe you can show more of your setup, so we can understand > package specific constraints. I'm starting with a system of homegrown makefiles. Lots of directories, lots of recursive make invocations. As well, there's a central directory where include files get "installed" to. That's the directory in the include path. When I add a new directory, I use automake/autoconf. Each automake/autoconf directory is completely independent at the moment. And, they follow the same convention of #including header files from the central location. To pull this off I pass --prefix to configure and run a make install. This breaks the dependency information and more stuff gets rebuilt than is necessary. I can resolve this by adding the paths where the header files live before installing them (and taking out the install operation). I figured I would give a shot to the full-on non-recursive make at the same time. > the configure.ac together with their AC_CONFIG_SUBDIRS() > links form an acyclic directed graph (tree); each > Makefile.am that stands on its own (i.e., is not included by > another Makefile.am), should be listed (with name Makefile) > in AC_CONFIG_FILES of exactly one configure.ac, otherwise > havoc will ensue. Makes sense. If I'm including Makefile.am fragments, I need to make sure there's only one AC_CONFIG_FILES([Makefile]). > Wait.. you have a configure.ac for each directory? That is > really rare. Usual setup is to have one configure.ac per > software package, and a bunch of Makefile.am. More than one > configure.ac is only necessary or useful to > > - bundle rather independent packages (also to remain rather > independent) Here's an overview of what I've got. top/app_1 top/app_2 top/related_libs_1 top/related_libs_1/lib_1_a top/related_libs_1/lib_1_b top/related_libs_1/lib_1_c top/related_libs_2 top/related_libs_2/lib_2_a top/related_libs_2/lib_2_b top/related_libs_2/lib_2_c No shared libraries. Everything statically linked. When we release something, it's either app_1 or app_2. Let's say app_1 links with lib_1_a, lib_2_a, and lib_2_b. app_2 links with lib_1_a and lib_2_c. When people work, they typically either work on app_1 or app_2. Either way they get all of related_libs_1 and related_libs_2. If I treat all the lib_*_* as totally independent, everything pretty much works. I configure, make, make install in each directory. But, too much stuff gets rebuilt because everything depends on files in the install destination and those timestamps change because the install recipe makes a new copy every time. As I said above I think I can fix that, but the other benefits of one big Makefile are tempting. Ideally I'd like one big one for app_1 and one for app_2. Note that there's nothing in the top directory at the moment...No makefile, Makefile.am, configure.ac...nothing. It's a consequence of the way we're using revision control. I can't put anything there. (Each of app_1, app_2, related_libs_1, and related_libs_2 are clearcase VOBs. The top level directory isn't in a VOB so nothing can go there.) I bet as I add more autotools-aware libraries that I'll be duplicating a bunch of configure tests. It would be nice to avoid that as well. I guess I can share cache files...Not exactly sure what my options are here, especially with the top of the directory tree forbidden. If I have to move everything around, I'll consider it, but I'm not sure what a good solution is. I can make a giant VOB with everything in it so the top level becomes a valid place to put files. My reflex is to have app_1 and app_2 not know anything about each other (i.e. have totally separate Makefile.am's, configure.ac's), but I bet the normal way to pull this off is to have one configure.ac and one Makefile.am for both and define two targets in Makefile.am. Is that right? Sorry for being long-winded. If you've gotten this far and have some suggestions I'd love to hear them. Thank you. -DB
