You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Christopher Ness <ch...@nesser.org> on 2006/07/17 19:38:00 UTC
Dev Build System: Include Revision Number
Does anyone out there have a patch to update the build system so that it
includes the revision number the source was built from in
`/subversion/include/svn_version.h`
SVN_VER_TAG
SVN_VER_NUMTAG
Instead of the non-descriptive development strings?
I'd like to know what revision I'm running without having to find the
working copy I built the source from.
Please note I'm not suggesting removing the dev strings, I feel it is
still important to know a development version of the code is used, but I'd
also like to know the revision.
Cheers,
Chris
--
http://www.nesser.org
--
http://www.nesser.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dev Build System: Include Revision Number
Posted by Sigfred Håversen <bs...@mumak.com>.
The hardware requirements for running/using/building
Subversion are quite high, and this is well known.
Relinking does not take that much time, relatively
speaking, so I still don't understand your very strong
objection.
/Sigfred
Michael Brouwer wrote:
> Why not only relink if the output of svnversion changes?
>
> Michael
>
>
> On 7/17/06, *Sigfred Håversen* <bsdlist@mumak.com
> <ma...@mumak.com>> wrote:
>
> Max Bowsher wrote:
> > Christopher Ness wrote:
> >
> >>Does anyone out there have a patch to update the build system so
> that it
> >>includes the revision number the source was built from in
> >>`/subversion/include/svn_version.h`
> >>
> >> SVN_VER_TAG
> >> SVN_VER_NUMTAG
> >>
> >>Instead of the non-descriptive development strings?
> >>
> >>I'd like to know what revision I'm running without having to find the
> >>working copy I built the source from.
> >>
> >>Please note I'm not suggesting removing the dev strings, I feel
> it is
> >>still important to know a development version of the code is
> used, but I'd
> >>also like to know the revision.
> >
> >
> > It's deliberately not done to avoid needing to run 'svnversion', and
>
> That is understandable :-) Very useful feature, but not for every "make"
> as you point out.
>
> > relink everything from libsvn_subr on upwards, on *every*
> invocation of
> > 'make'.
> > Ideas welcome, but clearly relinking the entire libsvn_foo
> library stack
> > on every 'make' is unacceptable.
>
> This one I don't understand.
>
> /Sigfred
>
>
> /Sigfred
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> <ma...@subversion.tigris.org>
> For additional commands, e-mail: dev-help@subversion.tigris.org
> <ma...@subversion.tigris.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dev Build System: Include Revision Number
Posted by Max Bowsher <ma...@ukf.net>.
Michael Brouwer wrote:
> Why not only relink if the output of svnversion changes?
It's a possibility - depends on whether people are happy with
'svnversion' running on every make.
Max.
Re: Dev Build System: Include Revision Number
Posted by Michael Brouwer <mb...@gmail.com>.
Why not only relink if the output of svnversion changes?
Michael
On 7/17/06, Sigfred Håversen <bs...@mumak.com> wrote:
>
> Max Bowsher wrote:
> > Christopher Ness wrote:
> >
> >>Does anyone out there have a patch to update the build system so that it
> >>includes the revision number the source was built from in
> >>`/subversion/include/svn_version.h`
> >>
> >> SVN_VER_TAG
> >> SVN_VER_NUMTAG
> >>
> >>Instead of the non-descriptive development strings?
> >>
> >>I'd like to know what revision I'm running without having to find the
> >>working copy I built the source from.
> >>
> >>Please note I'm not suggesting removing the dev strings, I feel it is
> >>still important to know a development version of the code is used, but
> I'd
> >>also like to know the revision.
> >
> >
> > It's deliberately not done to avoid needing to run 'svnversion', and
>
> That is understandable :-) Very useful feature, but not for every "make"
> as you point out.
>
> > relink everything from libsvn_subr on upwards, on *every* invocation of
> > 'make'.
> > Ideas welcome, but clearly relinking the entire libsvn_foo library stack
> > on every 'make' is unacceptable.
>
> This one I don't understand.
>
> /Sigfred
>
>
> /Sigfred
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: Dev Build System: Include Revision Number
Posted by Sigfred Håversen <bs...@mumak.com>.
Max Bowsher wrote:
> Sigfred Håversen wrote:
>
>>Max Bowsher wrote:
>>
>>>Christopher Ness wrote:
>>>
>>>
>>>>Does anyone out there have a patch to update the build system so that it
>>>>includes the revision number the source was built from in
>>>>`/subversion/include/svn_version.h`
>>>>
>>>>SVN_VER_TAG
>>>>SVN_VER_NUMTAG
>>>>
>>>>Instead of the non-descriptive development strings?
>>>>
>>>>I'd like to know what revision I'm running without having to find the
>>>>working copy I built the source from.
>>>>
>>>>Please note I'm not suggesting removing the dev strings, I feel it is
>>>>still important to know a development version of the code is used,
>>>>but I'd
>>>>also like to know the revision.
>>>
>>>
>>>It's deliberately not done to avoid needing to run 'svnversion', and
>>
>>That is understandable :-) Very useful feature, but not for every "make"
>>as you point out.
>>
>>
>>>relink everything from libsvn_subr on upwards, on *every* invocation of
>>>'make'.
>>>Ideas welcome, but clearly relinking the entire libsvn_foo library stack
>>>on every 'make' is unacceptable.
>>
>>This one I don't understand.
>
>
> The version information is (currently) compiled into libsvn_subr. Change
> libsvn_subr, and everything depending on it (which is *everything*) gets
> rebuilt (relinked).
Ah, if it's rebuilt and not just relinked I understand MB's objection.
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dev Build System: Include Revision Number
Posted by Max Bowsher <ma...@ukf.net>.
Sigfred Håversen wrote:
> Max Bowsher wrote:
>> Christopher Ness wrote:
>>
>>> Does anyone out there have a patch to update the build system so that it
>>> includes the revision number the source was built from in
>>> `/subversion/include/svn_version.h`
>>>
>>> SVN_VER_TAG
>>> SVN_VER_NUMTAG
>>>
>>> Instead of the non-descriptive development strings?
>>>
>>> I'd like to know what revision I'm running without having to find the
>>> working copy I built the source from.
>>>
>>> Please note I'm not suggesting removing the dev strings, I feel it is
>>> still important to know a development version of the code is used,
>>> but I'd
>>> also like to know the revision.
>>
>>
>> It's deliberately not done to avoid needing to run 'svnversion', and
>
> That is understandable :-) Very useful feature, but not for every "make"
> as you point out.
>
>> relink everything from libsvn_subr on upwards, on *every* invocation of
>> 'make'.
>> Ideas welcome, but clearly relinking the entire libsvn_foo library stack
>> on every 'make' is unacceptable.
>
> This one I don't understand.
The version information is (currently) compiled into libsvn_subr. Change
libsvn_subr, and everything depending on it (which is *everything*) gets
rebuilt (relinked).
Max.
Re: Dev Build System: Include Revision Number
Posted by Sigfred Håversen <bs...@mumak.com>.
Max Bowsher wrote:
> Christopher Ness wrote:
>
>>Does anyone out there have a patch to update the build system so that it
>>includes the revision number the source was built from in
>>`/subversion/include/svn_version.h`
>>
>> SVN_VER_TAG
>> SVN_VER_NUMTAG
>>
>>Instead of the non-descriptive development strings?
>>
>>I'd like to know what revision I'm running without having to find the
>>working copy I built the source from.
>>
>>Please note I'm not suggesting removing the dev strings, I feel it is
>>still important to know a development version of the code is used, but I'd
>>also like to know the revision.
>
>
> It's deliberately not done to avoid needing to run 'svnversion', and
That is understandable :-) Very useful feature, but not for every "make"
as you point out.
> relink everything from libsvn_subr on upwards, on *every* invocation of
> 'make'.
> Ideas welcome, but clearly relinking the entire libsvn_foo library stack
> on every 'make' is unacceptable.
This one I don't understand.
/Sigfred
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dev Build System: Include Revision Number
Posted by Branko Čibej <br...@xbc.nu>.
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
>>>> '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?
>
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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dev Build System: Include Revision Number
Posted by Max Bowsher <ma...@ukf.net>.
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.
Re: Dev Build System: Include Revision Number
Posted by Christopher Ness <ch...@nesser.org>.
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.
The python script is attached, just use the above make commands and put
the python script in after the || (or) command.
You would want to `cat` the contents of the version file instead of
running `svnversion` again as I show in the usage of the script.
Or just run the script in the ./subversion/include/ directory and build
the source.
Please let me know if you find any bugs in the python script.
I think the 'svn_version.h' target would have to depend on the
'versionfile' target in the Makefile so things get built in the right
order. But I'm not sure of that one.
Relinking is non-trivial as originally pointed out. After changing the
source header file make reports that 234 commands need to execute to build
the executable.
[cgness@servicesvn dev-rev-devel]$ make -n | wc -l
234
Thanks for the chatter, I received more of a response than I expected.
Cheers,
Chris
--
http://www.nesser.org
Re: Dev Build System: Include Revision Number
Posted by Greg Hudson <gh...@MIT.EDU>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Dev Build System: Include Revision Number
Posted by Max Bowsher <ma...@ukf.net>.
Christopher Ness wrote:
> Does anyone out there have a patch to update the build system so that it
> includes the revision number the source was built from in
> `/subversion/include/svn_version.h`
>
> SVN_VER_TAG
> SVN_VER_NUMTAG
>
> Instead of the non-descriptive development strings?
>
> I'd like to know what revision I'm running without having to find the
> working copy I built the source from.
>
> Please note I'm not suggesting removing the dev strings, I feel it is
> still important to know a development version of the code is used, but I'd
> also like to know the revision.
It's deliberately not done to avoid needing to run 'svnversion', and
relink everything from libsvn_subr on upwards, on *every* invocation of
'make'.
Ideas welcome, but clearly relinking the entire libsvn_foo library stack
on every 'make' is unacceptable.
Max.