Max Bowsher wrote:
> Christopher Ness wrote:
>> On Tue, July 18, 2006 12:33 pm, Greg Hudson said:
>>> On Mon, 2006-07-17 at 21:34 +0100, Max Bowsher wrote:
>>>> It's deliberately not done to avoid needing to run 'svnversion', and
>>>> relink everything from libsvn_subr on upwards, on *every* invocation of
>>> svnversion . >> versionfile.new
>>> cmp versionfile versionfile.new || mv versionfile.new versionfile
>>> I believe that should work with every modern version of make (I've seen
>>> versions which won't re-check the timestamp on versionfile after
>>> executing the rebuild rule, but I think that's ancient history).
>>> svnversion would run on every build, but that's it, and repeated
>>> invocations of svnversion should be quite fast for a Subversion project
>> Thanks for the "make magic" Greg. I think you wanted to overwrite
>> versionfile.new instead of append to it though.
>> Once the version number is segregated into it's own file, it would still
>> need to be updated in the source header to reflect the version number when
>> the `cmp` command returned non-zero.
>> I've been writing a python script to do this - which is not the greatest
>> implimentation as I wouldn't want to add a requirement for python to
>> subversion. A proper C program could be written for cross platform
>> implimentations if this is seen as useful.
> There's a perfectly good sed command in dist.sh.
> In the case of the Windows build, I think that requires Python anyway.
> Something which has _not_ been addressed yet is that this would make
> svn_version.h be changed by the build-system - which would make it
> continually show up as modified and committable, which is clearly not
> helpful for development. If we care enough about this, I suppose we
> could version-control svn_version.h.in, and have the build-system
> generate svn_version.h. Do we care enough?
Personally I don't see a single good reason for doing all this in the
first place. Add the target to the makefile by all means, but whoever
uses it shouldn't scream if they get a conflict in version.h down the line.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 19 10:38:34 2006