automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Public header files


From: Ralf Wildenhues
Subject: Re: Public header files
Date: Mon, 15 Mar 2010 22:18:59 +0100
User-agent: Mutt/1.5.20 (2009-10-28)

* Jef Driesen wrote on Sat, Mar 13, 2010 at 11:21:45PM CET:
> On 13/03/10 11:34, Ralf Wildenhues wrote:
> >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.

True, and a good rationale for using it.

> 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.

Well, you can usually emulate such things with a helper #define and
conditional #if/#ifdef code in the manually written header.

> >>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.

Well, that solution has the disadvantage that a revision change causes a
full autotools and configure rerun, but yes, that is one suboptimal
solution.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]