Arch Linux

imo is a bug in hybrid-encoder and they should use pkg-config to check the existance of x264

Presence of x264 in system is done correctly in hybrid encoder. It's the revision check that fails (0.120.x vs 0.120.2164). Alternative solution is to patch x264 and repace "x" with revison number (file x264_config.h after ./configure).

Possible fix

./configure --enable-shared
#fix
sed -i "s|0.120.x|0.120.REV_NUM|g" x264_config.h

submit that to x264 devs. I won't add that sed workaround because every time soname changes I have to change the sed as well.

Any news?

Thanks for reminding this bug report. I was too lazy ;) to report this upstream so I figure out a workaround. It's fully automatic ;)

The upstream has a method to get the version of the x264 since beginning of the project (the method is the same, only changes the VCS used).

This method is:

when configure is executed (with or withour arguments) it calls the version.sh script, to see the total number of commits that the repository has.

[1], Exactly [2]...

If the whole script is read, with this total number of commits (and some equations) determines the build.

The Zip has no folder .git to generate the version, but if the git repository is used, it will fix the problem, because the x264 repository has the master and stable heads.
Master is under development, but stable freezes when the whole code has been tested.

No need for sed workground, just (the real problem) to stablish the variable pkgver= with the info generated by version.sh, but this only works if the repository is cloned
and extracting the info from the x264_config.h file before launching build() function in the pkgbuild.

I've not found the method to get all the info from the repository like git rev-list in the local repository. Only if a painful hack is built:

Download from [3] with curl -sL (pg=0 is a variable that determines the number of pages that the log has; this number increments if you add more commits to the repository.
Today, the log has 22 pages; tomorrow, or in a month, it might have 30... or 50...), extract the hash from the commits, run the command uniq to eliminate the repeated commits,
and make your own algorithm (like in the version.sh) to get the version.

I'm working on it. For now, only this works:

_getver() {
msg "Connecting to server to get version"
rm -fr .temp
git clone "${_gitroot}" .temp > /dev/null 2>&1
cd .temp
./configure > /dev/null 2>&1
echo "$(< x264_config.h)" | grep X264_VERSION | cut -d ' ' -f4 | cut -b2-
cd ..
rm -fr .temp
}

pkgver="$(_getver)"

and running a clonation for the second time in the function build()

if anyone have any idea to complete this (without cloning the repository twice and with compatibility with pkgbuild), you'd make me a wooden son.

greetings

[1] http://git.videolan.org/?p=x264.git;a=blob;f=version.sh;h=5466ef242d2cecffb886fa5b9a819a8b1b4af846;hb=HEAD
[2] http://git.videolan.org/?p=x264.git;a=blob;f=version.sh;h=5466ef242d2cecffb886fa5b9a819a8b1b4af846;hb=HEAD#l6
[3] http://git.videolan.org/?p=x264.git;a=log;h=refs/heads/stable;pg=0