Joerg Mayer wrote:
On Thu, Aug 04, 2011 at 08:20:55PM +0000, cmaynard@xxxxxxxxxxxxx wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=38340
User: cmaynard
Date: 2011/08/04 01:20 PM
Log:
Don't report svn version if not building from svn. Change prompted by http://ask.wireshark.org/questions/5376/wireshark-161-title-shows-svn-rev-unknown-from-unknown.
Directory: /trunk/
Changes Path Action
+3 -2 make-version.pl Modified
Does this really make sense? How do you differentiate between the "real"
1.6.1 release and a post 1.6.1 source code archive?
I think this particular "fix" is wrong.
The only way I see to get around that, though, is to have each official
release (e.g., 1.6.1) have a commit to disable the SVN version noise and
then another commit to re-enable it after the release is made.
(We do actually put non-official-release source tarballs from the
release branches in http://www.wireshark.org/download/prerelease/ )
What about:
1) put Chris' code back in
2) *In the release branches only* apply a change like the below
3) Make make-version.pl generate an empty svnversion.h when called with
"-p" (now it doesn't create any file which causes the #includes to fail)
That would mean users building from (official release) source would not
get SVN the version noise. Pre-release users wouldn't either, but
development release users would get it.
I do think it doesn't look good to have released version saying
"unknown" just because a user built from the source (which I expect most
non-Windows users to do).
Index: Makefile.am
===================================================================
--- Makefile.am (revision 38333)
+++ Makefile.am (working copy)
@@ -488,7 +488,7 @@
FORCE:
svnversion.h: FORCE
- $(PERL) $(srcdir)/make-version.pl $(srcdir)
+ $(PERL) $(srcdir)/make-version.pl -p $(VERSION) $(srcdir)
#
# Build shell scripts by doing variable substitution.
