Re: Public header files

[Jef Driesen]

On 13/03/10 11:34, Ralf Wildenhues wrote:
> * Jef Driesen wrote on Mon, Mar 08, 2010 at 02:10:04PM CET:
> > On 02/03/10 22:17, Ralf Wildenhues wrote:
> > > Hmm, put
> > >    AC_CONFIG_HEADERS([config.h foo-api.h])
> > >    ...
> > >    AC_DEFINE([ticks_t], [...], [...])
> > >
> > > in configure.ac, create foo-api.h.in with contents
> > >    /* Public API header of package Foo */
> > >    ...
> > >    #undef ticks_t
> > >
> > > and add foo-api.h to include_HEADERS in Makefile.am.  Untested,
> > > be sure to test distcheck.
> >
> > In case anyone is interested, at the end of this post you can find
> > the solution that I'm using now.
>
> You are using a AC_CONFIG_FILES now instead of a AC_CONFIG_HEADERS.
> That's fine per se, but config files are updated unconditionally by
> config.status, meaning that the updated timestamp might cause more
> rebuilds than necessary.

I used AC_CONFIG_FILES because I had the impression that was more 
powerfull than AC_CONFIG_HEADERS, in the sense that I can do more than 
just defining values. For instance, I prefer to have:

typedef foobar ticks_t;

instead of:

#define ticks_t foobar

It might be possible to achieve the same with AC_CONFIG_HEADERS, but I 
don't know how. I had a look at a number of projects to see how they did 
this, and they used AC_CONFIG_FILES.

> > The next thing I want to add is a MYLIB_VERSION_REVISION, that
> > contains some info from the SCM system (e.g. a svn revision number,
> > a git sha1 hash). When building a (not yet released) development
> > version of my code, it would be useful to know the exact revision.
>
> There's been quite some prior discussion and examples of this in the
> list archives, but a perfect solution still would require some changes
> to Automake.

I suppose you are referring to solutions like this:

m4_define([mylib_version_revision],m4_esyscmd([my_revision_script]))

where the revision script fetches the revision from the SCM system, or 
from a version file when using tarballs.