Re: revision control info in generated files

[Jef Driesen]

On 01/04/10 20:31, Ralf Wildenhues wrote:
> * Jef Driesen wrote on Thu, Apr 01, 2010 at 02:34:29PM CEST:
> > On 31/03/10 22:45, Ralf Wildenhues wrote:
> > > * Jef Driesen wrote on Wed, Mar 31, 2010 at 02:49:48PM CEST:
> > > > Shouldn't the .git-version file be created inside the build directory,
> > > > rather than the source directory?
> > >
> > > No.  I want the .git-version file to be distributed, so that it is
> > > present in an extracted tarball that has no .git information.  There,
> > > the file will be in the source directory.  Might as well have it in the
> > > source directory in my git checkout as well then, to be consistent;
> > > otherwise, you may end up running into one of the 'make' portability
> > > issues documented in info Autoconf 'Make Target Lookup'.
> >
> > 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.

> One simple rule one can follow and have few VPATH problems is to put all
> files in the source tree which are added to the distribution.  And let
> no distributed file depend on an undistributed file.
>
> I'm not quite that strict; I have a couple of distributed files which
> may be updated in a build tree.  But all files which also need special
> tools (like git, makeinfo) to remake, and which are of course the same
> across systems, are updated in the source tree.  I like to be able to
> build from a git checkout on systems where these tools are not installed
> (git may not be installed on all of the system that see an NFS mount).

Make sense also if you consider that we are trying to find a workaround 
for a version generated at configure time, where the version file would 
also end up in the source tree. We are now "cheating" a little bit by 
(re-)generating that file in the makefile to avoid having to re-run 
configure every time.

> > I do not understand everything that is explained in the 'Make Target
> > Lookup' section, but it seems that not all make variants do build
> > everything in the build directory? And that could cause problems?
>
> Yes.
>
> > (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, what will happen when trying to build the second variant? If 
object files from the other build are picked up, problems will happen.

Or am I seeing this wrong? I only have experience with GNU make and use 
VPATH builds to cross compile windows and macosx binaries in addition to 
native linux binaries. So I'm probably not affected by any of this.


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)?