x265 reports version 0.0 when built from 2.1 release tarball

[Steve Borho]

reported by Handbrake team.

"There are basically 2 "bugs" in the x265 2.1 release. First, their repo info file $(TOP)/.hg_archive.txt has been populated differently than the last release. Not sure if this was intentional, or some error in their release process. Second, the cmake script source/cmake/version.cmake appears to initially construct a proper X265_VERSION from "latesttag" that it sees in .hg_archive.txt. Then at 9:42 AM the very end of the file, it overwrites this correct version info with 0.0. I think the error here is that they really meant to set X265_LATEST_TAG where they set X265_VERSION."

the changes in .hg_archive.txt should be harmless, but the cmake bugs are real. This needs to be fixed on stable and cut a new tag that builds with correct version info

[Steve Borho]

there were two root causes:

1) the tagging revision (3e8ce3b26319) was archived instead of the tagged revision (981e3bfef16a). I used hg archive to generate a tarball from the actual 2.1 tagged commit and when built it reports the version number correctly. So the fix to this problem should be to regenerate the tarballs from the correct commit, and name the new tarball x265_2.1_1.tar.gz

2) the cmake scripts do not handle .hg_archive.txt files for non-tagged commits correctly. this should be improved for the long term.

[Pradeep Ramachandran]

Thanks for the report. I have updated the tarball in the download section of the wiki (https://bitbucket.org/multicoreware/x265/downloads) from an archive generated at the revision where the 2.1 tag was added; building with this fixes the problem. The md5 sum on the wiki also has this md5 sum updated.

Just waiting on the ftp mirror to get the updated tarball before closing this issue.

[Pradeep Ramachandran]

The tar ball in the downloads page and the videolan ftp site have been updated to resolve this issue.