Re: Why does gnulib use makefile rules rather than configure?

[Bruno Haible]

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