Automatic autoheader invocations for AC_DEFINE changes in m4-files

[Marko Lindqvist]

We are in the middle of transition from one config header to model of
two config headers. The goal is that the new one will contain only
such macros that it can be safely #included by another project
(assuming another autotools using project, but it shouldn't really
matter)
Template for the full header continues to be generated by autoheader,
while the "public" one is using hand-written template. Each macro
included to the public header should have same prefix in their name to
have them all in the same namespace and not to conflict with similar
macros from other projets.

Typical patch in this development:
1) Adds an entry to the public header template
2) Changes name of the macro in AC_DEFINE to give it correct prefix
3) Updates references to the macro in source files to use the new name


We have had no problems with patches that do that for macros
AC_DEFINEd in configure.ac. When one runs 'make', both the full and
public header are correctly generated.
However, when the macro in question in one patch was AC_DEFINEd in a
separate m4-file, 'make' was not enough at all. Template for the full
header did not update until manual autoreconf.

It's nice that nowadays configure gets automatically regenerated when
m4-file changes, but it seems that autoheader invocations are still
not happening the same way.

Is there something we can/should do ourselves, or is this to be
considered use-case that is not yet supported by autotools?


- ML

[Eric Blake]

Post by Marko Lindqvist
We have had no problems with patches that do that for macros
AC_DEFINEd in configure.ac. When one runs 'make', both the full and
public header are correctly generated.
However, when the macro in question in one patch was AC_DEFINEd in a
separate m4-file, 'make' was not enough at all. Template for the full
header did not update until manual autoreconf.

This is more of an automake question than an autoconf one (since it is
automake that generates the make rules for what needs to be rebuilt
when). Do you have AC_CONFIG_MACRO_DIR([...]) in your configure.ac,
pointing to the location of your .m4 files? Likewise, in your
Makefile.am, do you have ACLOCAL_AMFLAGS = -I path/to/m4? I've found in
my projects that both places are needed to inform automake that it must
generate proper dependency tracking so that a change to a .m4 file
forces an automatic autoreconf.

[Luke Mewburn]

On Wed, Feb 10, 2016 at 10:10:31PM +0200, Marko Lindqvist wrote:
| We are in the middle of transition from one config header to model of
| two config headers. The goal is that the new one will contain only
| such macros that it can be safely #included by another project
| (assuming another autotools using project, but it shouldn't really
| matter)

I think that this is a great idea, and I use a variation
of it in a couple of projects.
I find it problematic when third-party projects ship a "config.h"
in their public include directory, especially when that directory
is directly referenced with -I, or when their renamed config.h variation
provides #defines with the autoconf default definitions.


| Template for the full header continues to be generated by autoheader,
| while the "public" one is using hand-written template. Each macro
| included to the public header should have same prefix in their name to
| have them all in the same namespace and not to conflict with similar
| macros from other projets.

Have you considered implementing your own macro variation of
AH_TEMPLATE() for this? You could then AC_DEFINE the new variables
(at the end of configure.ac) in terms of the values determined
for the base value. In my humble opinion, this could be a useful
feature for the autoconf archive if not base autoconf.


cheers,
Luke.