Sweet spot between AC_CONFIG_FILES, AC_CONFIG_HEADERS, and AC_CONFIG_COMMANDS

[Behdad Esfahbod]

While I'm on it, lemme also give some feedback on autoconf.
This is not really a bug report, but a usability feedback  on the
AC_CONFIG_FOOS family.

There are two common use cases I see that are not currently addressed by any
of those macros:

1) Public configuration headers:

Many projects have a public header that needs to be generated from configure.
 These either reflect enabled features of the build, things like size of some
types etc that are needed in the public headers of the project, or just the
version number of the project.

The most common approach to generating these things that I've seen has been to
use AC_CONFIG_COMMANDS and assemble them together manually.  Then one needs to
be alert enough to generate to a temp file and not touch the original file if
the contents didn't change.  Otherwise a complete rebuild of the project is
triggered.

Now, that's very similar to what AC_CONFIG_HEADERS does.  Except that I fail
to understand how multiple config headers can be used with that macro and in
conjunction with acheader.   Ideally I should be able to do something like:

AC_CONFIG_HEADERS([config.h src/cairo-features.h])

AH_TOP(src/cairo-features.h,[#ifndef CAIRO_FEATURES_H
#define CAIRO_FEATURES_H 1])

AH_BOTTOM(src/cairo-features.h,[#endif /* CAIRO_FEATURES_H */])

AC_DEFINE(src/cairo-features.h:CAIRO_HAS_XLIB_SURFACE, 1,
[Define if cairo's Xlib surface backend is enabled])


That's one.


2) Same thing but not for headers necessarily:

Ok, two things:

  * I see that there's a comment in AC_CONFIG_FILES implementation about not
touching the file if the contents didn't change, but that is not enabled
because "it breaks make dependencies".  That's true.  But sometimes the lazy
behavior is desired.  Something like AC_CONFIG_FILES_LAZY would solve that need.

  * Sometimes generating a template is really harder than just generating the
content.  So I have this macro for myself that is like AC_CONFIG_COMMANDS but
a) redirects the contents of COMMANDS to the tag file, and b) is lazy in
touching the file:

dnl CAIRO_CONFIG_COMMANDS is like AC_CONFIG_COMMANDS, except that:
dnl
dnl     1) It redirects the stdout of the command to the file.
dnl     2) It does not recreate the file if contents didn't change.
dnl
AC_DEFUN([CAIRO_CONFIG_COMMANDS],
[dnl
        AC_CONFIG_COMMANDS($1,
        [
                _config_file=$1
                _tmp_file=cairoconf.tmp
                AC_MSG_NOTICE([creating $_config_file])
                {
                        $2
                } >> "$_tmp_file" ||
                AC_MSG_ERROR([failed to write to $_tmp_file])

                if cmp -s "$_tmp_file" "$_config_file"; then
                  AC_MSG_NOTICE([$_config_file is unchanged])
                  rm -f "$_tmp_file"
                else
                  mv "$_tmp_file" "$_config_file" ||
                  AC_MSG_ERROR([failed to update $_config_file])
                fi
        ], $3)
])


I'd love to know if I've been missing easier ways to achieve the above with
autotools.

(If not clear, I've been hacking on cairo's build system for a full week now.
 Donno love all the flexibility autoconf/m4 gives me or hate it, but I did end
up writing a lot of custom macros, including but not limited to, generating
part of my Makefile.am's:

  http://cgit.freedesktop.org/cairo/tree/
)

Regards,

behdad