Local builds from source tar balls or the two phase wsjtx-superbuild
no longer specify any revision, just the version number. Since these
sort of builds are expected to be release candidates or release
versions the revision (svn changeset number) is implicit from the svn
tag of the version.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-1.4@4984 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Subversion keyword expansion of $Rev:$ in a file is hopeless as it is
impossible to coordinate with a release. Revert to an empty string
when it can't be discovered with svn info etc..
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx-1.4@4983 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Use the WSJTX_RC variable in Versions.cmake to label and identify
program and packages.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4338 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
all types of build.
CMake builds use 'svn info' (the git-svn equivalent is also supported)
to get the real latest revision of the workspace that is used to
source a build. If the sources are not in VCS workspace (build from
source snapshot archive for example) then the $Rev$ svn keyword
expansion in mainwindow.cpp is used despite its issues with accuracy.
Non-CMake builds use the $Rev$ keyword expansion where possible.
If a CMake build is from a VCS workspace with local modifications; a
'-dirty' suffix is added to the revision number to denote that.
If no revision number information can be found the word 'local' is
used as a revision number.
The revision specification is used in the WSJT-X "about" box and is
sent to PSKReporter.info as part of the local station information
(this can be viewed at the statistics page
http://pskreporter.info/cgi-bin/pskstats.pl).
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4017 ab8295b8-cf94-4d9e-aec4-7959e3be5d79