Re: revision control info in generated files

[Jef Driesen]

On 02/04/10 11:58, Ralf Wildenhues wrote:
> * Jef Driesen wrote on Fri, Apr 02, 2010 at 11:45:20AM CEST:
> > On 01/04/10 20:31, Ralf Wildenhues wrote:
> > > * Jef Driesen wrote on Thu, Apr 01, 2010 at 02:34:29PM CEST:
> > > > Since the .git-version file is a generated file, I would think it
> > > > belongs in the build directory, where all other generated files end
> > > > up.
> > >
> > > configure and Makefile.in files are generated files, too.
> >
> > True, but they are generated by autoconf and friends, not while
> > running make to compile the code. And I was referring to that last
> > one.
>
> My makefile often calls autoconf.  I usually have
> --enable-maintainer-mode set, or do not use AM_MAINTAINER_MODE.

When I modify configure.ac and run make, the configure runs 
automatically, so i suppose I'm also using maintainer mode. Although I 
never enabled or disabled it explicitly.

> Where do you get the idea that an object file can end up in the source
> tree?  That would be a bug.

I thought that's what that autoconf info page was about, but ...

> > Or am I seeing this wrong?
>
> I think so.  The portability issues revolve mostly around the case where
> there already exists a file matching the target, but is is out of date.
> Then the question is where to put the updated file.

... it seems I'm misunderstanding a few things. I'm not exactly an 
autotools expert. Just a user trying to get it working :-)

> > BTW, with your approach the version.c file is very simple (one
> > line). But what if it needs to contain some additional, non
> > generated content? For instance the functions to access the version
> > info? How would you do that? Something like a template file with a
> > placeholder maybe (like autoconf does for its *.in files)?
>
> Actually, my version.c was a bit more complicated in one case, and that
> also explained why I put it in the build tree (and there, added it to
> nodist_*_SOURCES): it also added something like
>    const char datadir[] = "$(datadir)";
>
> If you want something more complex, you can either write a more complex
> makefile rule.  You could also run config.status if you prefer that, but
> avoiding the slow path was part of the exercise here, wasn't it?  With
> C, you can always just write a minimal file to include elsewhere; just
> remember that if you do that, to add the file to BUILT_SOURCES so that
> it is updated early.

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

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

Ideally the revision info would go into my version.h file (like I could 
when fetching the revision info in configure.ac), because that is 
included everywhere I need the version info. But I'm not sure that is 
possible.