[Top][All Lists]

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

Re: revision control info in generated files

From: Jef Driesen
Subject: Re: revision control info in generated files
Date: Fri, 02 Apr 2010 13:04:57 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100217 Lightning/1.0pre Shredder/3.0.3pre

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

configure and 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

My makefile often calls autoconf.  I usually have
--enable-maintainer-mode set, or do not use AM_MAINTAINER_MODE.

When I modify 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 template that contains:


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, because that is included everywhere I need the version info. But I'm not sure that is possible.

reply via email to

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