[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 11:45:20 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100217 Lightning/1.0pre Shredder/3.0.3pre

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

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


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

reply via email to

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