Both are impossible to do without checking out the git repository. The first one MIGHT be possible via the google code api, you'd have to write a custom script for that, though...
For getting a revision number, x264 uses this script:
Code:
#!/bin/bash
git rev-list HEAD | sort > config.git-hash
LOCALVER=`wc -l config.git-hash | awk '{print $1}'`
if [ $LOCALVER \> 1 ] ; then
VER=`git rev-list origin/master | sort | join config.git-hash - | wc -l | awk '{print $1}'`
if [ $VER != $LOCALVER ] ; then
VER="$VER+$(($LOCALVER-$VER))"
fi
if git status | grep -q "modified:" ; then
VER="${VER}M"
fi
VER="$VER $(git rev-list HEAD -n 1 | cut -c 1-7)"
echo "#define X264_VERSION \" r$VER\""
else
echo "#define X264_VERSION \"\""
VER="x"
fi
rm -f config.git-hash
API=`grep '#define X264_BUILD' < x264.h | sed -e 's/.* \([1-9][0-9]*\).*/\1/'`
echo "#define X264_POINTVER \"0.$API.$VER\""
It's a shell script, but the commands used are obvious. This could be reworked to work on all supported platforms.
The revision number itself is basically a sum of the commits. It's not quite the same as an actual revision number and it should be used alongside a git hash.
When running "x264 --version" this output is provided:
x264 0.116.2037 f8ebd4a
The revision number is 2037 and the first 8 characters of the hash are provided.
I looked for some numbering scripts when the switch was done, but other people had suggested it and the devs didn't seem interested... I don't see how it could harm tough, would make it easier for the wiki and for the translation team....
Fwiw, I think for the translations think there are more elegant solutions than this... (pot file separate versioning maybe?)
(09-09-2011, 06:11 AM)imk Wrote: [ -> ]For getting a revision number, x264 uses this script:
Code:
#!/bin/bash
git rev-list HEAD | sort > config.git-hash
LOCALVER=`wc -l config.git-hash | awk '{print $1}'`
if [ $LOCALVER \> 1 ] ; then
VER=`git rev-list origin/master | sort | join config.git-hash - | wc -l | awk '{print $1}'`
if [ $VER != $LOCALVER ] ; then
VER="$VER+$(($LOCALVER-$VER))"
fi
if git status | grep -q "modified:" ; then
VER="${VER}M"
fi
VER="$VER $(git rev-list HEAD -n 1 | cut -c 1-7)"
echo "#define X264_VERSION \" r$VER\""
else
echo "#define X264_VERSION \"\""
VER="x"
fi
rm -f config.git-hash
API=`grep '#define X264_BUILD' < x264.h | sed -e 's/.* \([1-9][0-9]*\).*/\1/'`
echo "#define X264_POINTVER \"0.$API.$VER\""
It's a shell script, but the commands used are obvious. This could be reworked to work on all supported platforms.
The revision number itself is basically a sum of the commits. It's not quite the same as an actual revision number and it should be used alongside a git hash.
When running "x264 --version" this output is provided:
x264 0.116.2037 f8ebd4a
The revision number is 2037 and the first 8 characters of the hash are provided.
This script assumes you are running it from within a directory controlled by git (it is meant to be checked into a repository).
(09-09-2011, 11:05 AM)shuffle2 Wrote: [ -> ]This script assumes you are running it from within a directory controlled by git (it is meant to be checked into a repository).
With x264 this script is ran at the end of ./configure. It saves the output to a header file with definitions, which then get included by a source file and used. When incorporating it with MSVS, Xcode, or whatever else, the script could be ran prior to building. If the header file is not found, then some predefined settings will be used instead.
It is meant to be used only at configuration/build time, which would mean you likely already have git installed and the source cloned.
For release versions of the source, it can just use predefined settings without needing git.
I'm just throwing it out there as a possible solution.
