* 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
