Until now, it only used the hash from the previous configure run,
instead of trying to get the latest hash. The "old" build system did
this correctly - we just have to use the existing logic in version.sh.
Since waf supports separate build dirs, extend version.sh with an
argument for setting the path of version.h.
With the way I've been doing releases in the release/0.1 branch, this
proved completely useless. You need to write the VERSION file anyway,
and since we use github's automatically generated tarballs (via its
release system), the VERSION file needs to be in the git revision of
a release anyway. git master on the other hand displayed the v0.1.0
tag, because the tag is within the master branch.
This essentially reverts commit b27f65a. Now just print the contents
of the VERSION file if it exists, and likewise, we append the git
revision if it exists. (Do that even if VERSION exists, because this
way we can tell if someone is using the release branch at an in-between
point where no new release has been made yet.)
This is basically reconstructed from 46b218c. Since we now have proper
release tags, we want this again.
Add --tags to the git describe call, because the github release system
creates light-weight tags only, and we're too lazy to create annitated
tags (or is that bad practice?).
Add --long, so that the git commit hash is part of the output even if
the tag matches.
It appears git submodule handling recently changed, changing the .git
directory to a regular file containing submodule specific information.
This means that version.sh would generate "#define VERSION "git-UNKNOWN""
if the checkout is a submodule, because it explicitly checks for a .git
directory using test -d. Change it to -e so that this case is handled
correctly.
Based on a patch by qyot27. Add export LC_ALL=C on top of version.sh to
make the output locale independent.
Note that the build time will not be updated on every "make" invocation,
but only when the git revision is updated. This is a good thing, as
repeated make invocations should not rebuild the binary. (This would
break "sudo make install" too.)
Change the "main" name from "mplayer2" to "mplayer". Note that upstream
mplayer2 uses "MPlayer2", and mplayer uses "MPlayer", so it's
unambiguous.
The version.sh script used to put the latest tag into the version
script. The intention was to add a new tag on each release, but this
hasn't been done in over a year, making the tag absolutely pointless.
Remove it. Now "git-SHORTHASH" is used.
Remove the string "MPlayer & mplayer2 teams" after the copyright date,
because that sounded silly.
The name "MPlayer2" isn't used anywhere. It's either "MPlayer" or
"mplayer2". Make it more consistent by using "mplayer2" instead.
Note that the version string passed as network user-agent changes from
"MPlayer" to "mplayer2" as well.
Force Makefile to always run version.sh to potentially regenerate
version.h. Drop compiler version and 'git-' prefix from version
number. Match only git tags starting 'v'+number when generating
version number; leave the 'v' out from the result.
Also remove an old mention of "Subversion" from comments and fix an
error in non-git-repo version string generation (which hasn't been
used for anything).
Update the version.sh script for git so it'll generate version numbers
more useful than "UNKNOWN". At the moment it only generates the short
SHA1 name, but adding a tag as a starting point should allow more
useful output. Rather than update the Makefile logic that tried to
guess whether the svn revision had changed since the last version.h
update, just run the version.sh script from configure so the version
is updated at least at that time.
changed compared two lines to one, which would result in false positive updates.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@29140 b3059339-0415-0410-9bf9-f77b7e298cf2
This will be used by daily snapshots without Subversion metadata.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28728 b3059339-0415-0410-9bf9-f77b7e298cf2
Print CPU information in verbose mode instead of by default.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28360 b3059339-0415-0410-9bf9-f77b7e298cf2
