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.
