Re: revision control info in generated files

[Ralf Wildenhues]

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

> >>(Doesn't that cause trouble anyway when trying to use two different
> >>build directories with the same source directory?)
> >
> >Not when done right.  :-)  When files in the source tree need update,
> >I usually run the first 'make' serially; the rest should cope with
> >read-only source tree.  Hmm.
> 
> Suppose I'm building both 32 and 64bit binaries from the same source
> tree. Now, if object files from one variant can end up in the source
> tree,

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

> what will happen when trying to build the second variant? If
> object files from the other build are picked up, problems will
> happen.

Certainly.

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

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

Cheers,
Ralf