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
>>> 'make'.
>> versionfile:
>> 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
>> tree.
>
>
> 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?
Max.
Received on Tue Jul 18 20:24:45 2006