Including svn version number in --version output

It is very useful to have svn version number encoded in llvm-gcc’s --version output. Here is one approach.

Anyone has a better patch ?

Nope. I looked at how to do this and didn't find a good solution, so I think this is around the best that can be done.

Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555) (LLVM rXXXX)"

Where you set the revision number?

We currently use LLVM_VERSION_INFO to set this sort of information and to me it makes more sense to have the svn rev number there instead of just saying LLVM build like it does now.

-Tanya

Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555) (LLVM
rXXXX)"

Where you set the revision number?

I do not want to set the revision number in a source file every time I do 'svn update' :slight_smile:

We currently use LLVM_VERSION_INFO to set this sort of information and to
me it makes more sense to have the svn rev number there instead of just
saying LLVM build like it does now.

LLVM_VERSION_INFO indicates build numbers.

gcc does this with contrib/gcc_update which updates the file every update:

revision=`svn info | awk '/Revision:/ { print $2 }'`
branch=`svn info | sed -ne "/URL:/ {
s,.*/trunk,trunk,
s,.*/branches/,
s,.*/tags/,
p
}"`

where you now have revision and branch information.

-eric

Not everyone is at Apple. :slight_smile:

                                                 -Dave

Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555) (LLVM
rXXXX)"

Not everyone is at Apple. :slight_smile:

What is your point? You can always set LLVM_VERSION_INFO to be whatever you want. I'm talking about the case where it isn't set. And llvm-gcc is based on Apple gcc, so Apple will always be in the version line.

-Tanya

gcc does this with contrib/gcc_update which updates the file every
update:

revision=`svn info | awk '/Revision:/ { print $2 }'`
branch=`svn info | sed -ne "/URL:/ {
s,.*/trunk,trunk,
s,.*/branches/,
s,.*/tags/,
p
}"`

where you now have revision and branch information.

We don't want another commit after every other commit. This should be set by the makefile when a build is done.

This isn't a commit, it's just a file that's not under version control but created during update/checkout.

I suppose to be annoyingly pedantic about it you could require a network connection for the build, check svn info and svn status and then set the version string based on whether or not there are local patches applied to the checkout - but that would probably fall under neurotic :slight_smile:

-eric

Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555)
(LLVM
rXXXX)"

Where you set the revision number?

I do not want to set the revision number in a source file every time I
do 'svn update' :slight_smile:

Ok, so I'm confused. Don't you want the svn revision number to be shown when you do llvm-gcc --version? So why wouldn't you want to update it everytime you update and then compile? Shouldn't it match whatever svn version your build is using?

We currently use LLVM_VERSION_INFO to set this sort of information
and to
me it makes more sense to have the svn rev number there instead of
just
saying LLVM build like it does now.

LLVM_VERSION_INFO indicates build numbers.

Well, isn't that what you want? You are basically labeling a build with an svn revision number. Except instead of making someone set LLVM_VERSION_INFO you modify it for them when its not set (or use some other macro).

Perhaps I am misunderstanding what you want it to show when you do --version or how it is set.

-Tanya

I suppose to be annoyingly pedantic about it you could require a
network connection for the build, check svn info and svn status and
then set the version string based on whether or not there are local
patches applied to the checkout - but that would probably fall under
neurotic :slight_smile:

Using svnversion (as the original patch does) does exactly this. It outputs
the rev number, postfixed with "M" (for Modified) when there are local
changes.

This does not require a network connection, however, svn keeps a local clean
copy of everything (as opposed to CVS).

Gr.

Matthijs

I suppose to be annoyingly pedantic about it you could require a
network connection for the build, check svn info and svn status and
then set the version string based on whether or not there are local
patches applied to the checkout - but that would probably fall under
neurotic :slight_smile:

Using svnversion (as the original patch does) does exactly this. It outputs
the rev number, postfixed with "M" (for Modified) when there are local
changes.

:slight_smile: Probably the best way.

This does not require a network connection, however, svn keeps a local clean
copy of everything (as opposed to CVS).

Right. That I knew. I didn't know that rev was attached to it.

-eric

Ah, this is for llvm-gcc. I missed that. I thought we were talking about the
core LLVM, where it would be bad to brand it as coming from any single
entity.

                                                        -Dave

Yup.

Why not set the VERSUFFIX to be " (Based on Apple Inc. build 5555)
(LLVM
rXXXX)"

Where you set the revision number?

I do not want to set the revision number in a source file every time I
do 'svn update' :slight_smile:

Ok, so I'm confused. Don't you want the svn revision number to be
shown when you do llvm-gcc --version? So why wouldn't you want to
update it everytime you update and then compile? Shouldn't it match
whatever svn version your build is using?

I want build-llvm-gcc-but-rebuild-only-modified-files command to automatically pick up svn revision number, but I do not want to enforce "svn update" wrapper usage, if possible, to store svn revision number somewhere. And I do not want to reuse build number.

We currently use LLVM_VERSION_INFO to set this sort of information
and to
me it makes more sense to have the svn rev number there instead of
just
saying LLVM build like it does now.

LLVM_VERSION_INFO indicates build numbers.

Well, isn't that what you want? You are basically labeling a build
with an svn revision number. Except instead of making someone set
LLVM_VERSION_INFO you modify it for them when its not set (or use
some other macro).

Let's take example of checker build Ted produces on cfe-dev list. He regularly announces checker builds at http://clang.llvm.org/StaticAnalysis.html. The last one is checker-59 and it is not checker-(svn-revision-number). The build number, 59 in this example, is useful for the end user to connect the software build he received. The svn revision number is useful for the developer to track source base in svn. Usually, build number corresponds to a tag in svn tree.

We have LLVM_VERSION_INFO to set build number. We need another mechanism to track svn revision numbers. This will even useful when people try to track issues reported by nightly tester, for example.

Where you set the revision number?

I do not want to set the revision number in a source file every
time I
do 'svn update' :slight_smile:

Ok, so I'm confused. Don't you want the svn revision number to be
shown when you do llvm-gcc --version? So why wouldn't you want to
update it everytime you update and then compile? Shouldn't it match
whatever svn version your build is using?

I want build-llvm-gcc-but-rebuild-only-modified-files command to
automatically pick up svn revision number, but I do not want to
enforce "svn update" wrapper usage, if possible, to store svn revision
number somewhere. And I do not want to reuse build number.

I didn't say to force people to use svn update. I'm suggesting to use the svn revision number (via svnversion) as the build number. So that exactly as you are doing in your patch to Makefile.in, but I'm saying to use that svnversion number in the VERSUFFIX.

Let's take example of checker build Ted produces on cfe-dev list. He
regularly announces checker builds at http://clang.llvm.org/StaticAnalysis.html
. The last one is checker-59 and it is not checker-(svn-revision-
number). The build number, 59 in this example, is useful for the end
user to connect the software build he received. The svn revision
number is useful for the developer to track source base in svn.
Usually, build number corresponds to a tag in svn tree.

We have LLVM_VERSION_INFO to set build number. We need another
mechanism to track svn revision numbers. This will even useful when
people try to track issues reported by nightly tester, for example.

A build number can only correlate to a tag in the tree if one exists. In the case you are dealing with, its TOT.. so you only have the revision number to go by. So that can and should be used as the build number. You could come up with some arbitrary number to represent the build, but then you have to provide some mapping back to the developer when they want to track down bugs, so whats the point?

Where exactly are you suggesting to put the svnversion number in the version string then?

-Tanya

I forgot to include version.c change. Right now, I just append svnversion number at the end.

Ok. Sounds fine. :slight_smile:

-Tanya