Re: revision control info in generated files

[Peter Johansson]

On 4/2/10 7:04 AM, Jef Driesen wrote:
> The problem I'm trying to solve is that I already have a version.h 
> that is generated from a version.h.in template that contains:
>
> #define MYLIB_VERSION_MAJOR @MYLIB_VERSION_MAJOR@
> #define MYLIB_VERSION_MINOR @MYLIB_VERSION_MINOR@
> #define MYLIB_VERSION_MICRO @MYLIB_VERSION_MICRO@

I would extend version.h.in to also have a line

#define MYLIB_SVN_REVISION @MYLIB_SVN_REVISION@

and use sed to generate version.h from version.h.in where you replace 
@MYLIB_VERSION@ with values you already have AC_SUBSTed into Makefile 
and MYLIB_SVN_REVISION is replaced with content of 
$(top_srcdir)/.svn_revision. It might help to look at how Autoconf 
creates autoheader et al. from *.in files using edit.

http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables



> I also have a corresponding version.c file that has the same info, but 
> for use at runtime:
>
> #include "version.h
> const int mylib_version_major = MYLIB_VERSION_MAJOR;
> const int mylib_version_minor = MYLIB_VERSION_MINOR;
> const int mylib_version_micro = MYLIB_VERSION_MICRO;

This should not be a problem when you have the generated version.h. You 
can just use the defines from version.h. The tricky thing is that 
version.cc will not compile if version.h is not present (not generated 
yet), so you need to have a dependency that version.h needs to be 
generated before version.o is created.
Read the section 9.4 in Automake manual that explains the details clearly

http://sources.redhat.com/automake/automake.html#Sources


> (Or with functions to avoid the problem of exporting variables from 
> Windows DLL, but that's not relevant here.)
>
> It would be nice if I could get the revision info into the same file, 
> so related stuff is not spread over different files. No big deal if 
> that is not possible, but I also have other files where I could use 
> the revision info. For instance on windows I have a resource file 
> (*.rc) with version info. I can probably solve that by generating a 
> short version-revision.h file and include that.

It is a good idea to store the revision in a separate file, e.g., 
$(top_srcdir)/.svn_revision

It makes it easy to parse out that info and propagate to other places, 
and if you use the rule described by Ralf the time-stamp of this file 
will only change when the content needs to be changed, so you can have 
files depending on that time-stamp.

Cheers,
Peter