<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Fri, 2010-09-24 at 21:41 -0400, Trevor Woerner wrote: <BLOCKQUOTE TYPE=CITE> <TT>Yes, you are correct, I was looking to add a feature to replace a</TT> <TT>bunch of things that _i_ thought needed cleaning up. I'll prepare a</TT> <TT>set of patches to add this one feature and leave everything else out.</TT> </BLOCKQUOTE> Thanks it will be much easier. There is some information you should (and perhaps already) know. Regarding the current behavior of various make targets. Invoking "make" really does "make all"    which compiles and links all targets. Invoking "make" realy does "make all install" which compiles, links and install all targets. Invoking "make dist" will generate a tarball but will not do "make all". In some cases, it may cause the building of some documentation as it is included in the tarball. Invoking "make distcheck" will first invoke "make dist" and then proceed to perform a VPATH build equivalent to "make all install clean". The Automake folks call the distcheck target "a better dist". Problems can be found by distcheck which cannot be found by a regular build. There is something else about the relationship between configure and make. You may have noticed some changes causes the reconfiguration of the module. This is because of the Automake AM_MAINTAINER_MODE being in configure.ac *and* --enable-maintainer-mode being in autogen.sh. These are called the "maintainer build rules". There is a long story about this feature, with pros and cons. I made it consistent by adding these build rules where they were missing. So everything works the same way. Take into consideration that these build rules may not always be there, or may be removed in some modules. I speculate this is the reason why there is -a option to skip configuration if you know there were no changes that would otherwise cause the module to reconfigure. If you are doing a build with a rebase, you don't know which module may require a reconfigure. Relying on the maintainer build rules may not be wise. The safest (and longest) road is what is currently being done by default which is "configure && make install". Doing "make dist distcheck" is redundant, distcheck being the superset but much longer. Also take a moment to read INSTALL file in any of the module. It's a good primer and this is what the users will read, so we need to be in sync. Gaetan </BODY> </HTML>