Paul Smith wrote:
> I recognize there are some situations where make snippets are really
> the best way, but it seems like they're being used even in places where
> configure.ac would be just as simple. I think it would be a good
> "statement of policy" for gnulib that if there are equivalent ways of
> handling it, configuration.ac should be preferred over Makefile.
There are several reasons why gnulib uses Makefile.am snippets:
* [As Paul mentioned] sed substitutions in a Makefile rule are more
powerful than those supported by AC_CONFIG_FILES.
* There are cases in which we want to have a file generated in some
conditions only. (Example: modules/limits-h.) In such a case, there
is the need to remove the file when the developer switches from
a configuration which needs a generated limits.h to one that doesn't.
There is no place in configure.ac where this removal could be done.
Developers not always use
make -k distclean; ./configure; make
Sometimes they also do
./configure; make clean; make
and in such situations a mix between a generation rule in configure.ac
and a removal rule in the Makefile does not work well.
* The file hierarchy of the package is not something Gnulib can dictate;
it has to obey the file hierarchy given by the package's developers.
Through a long and painful experience (Jim may remember the AC_LIBOBJ
controversy...) we arrived at the conclusion that
- putting file/directory names into .m4 files must be avoided,
- putting file/directory names into the configure.ac part of a
module description can be done but needs careful coding,
- putting file/directory names into a Makefile.am snippet is a
no-brainer.
* Some packages build specific subdirectories only in specific
conditions. For example, GNU gettext builds its libasprintf/ directory
only when a C++ compiler is present. When you have a configure.ac rule
that generates a file in such a directory, it basically bypasses the
decision of the top-level Makefile whether to build the particular
subdirectory.
Again, this presents the risk of left-over files after "make distclean",
and similar trouble.
Therefore I disagree with your proposed "statement of policy".
Bruno
