I actually vote against this feature. INFO_* was created by someone who had only vague idea of CMake, with the purpose of learning cmake. The result is bad, the targets are always outdated. That piece of work, imo, should be removed.
For releases, revision corresponds to the git tag. CMake options are -DBUILD_CONFIG=mysql_release. If someone is really interested, which is hopefully not the case, then we should probably include the whole CMakeCache.txt, it has all the options.
I have no interest in reproducing the exact INFO_SRC/INFO_BIN files ... "something like this" would be fine 
The problem is not so much for releases, it's for custom or hotfix builds or builds created by customers or other users. It's important to be able to tell after-the-fact what actually was built, what options were used, and where it came from.
Even CMakeCache.txt won't say exactly what commit or branch something was built from, which is pretty important in trying to reproduce problems. And I think CMakeCache.txt also doesn't show which things were specified on the command line instead of being inferred or inherited from the environment, but I may be wrong about that.
If it is not so much for releases, but for custom builds, why the request to package them in our tarbin?
To cmake command line -there is no way to know the exact command line, even if if INFO_* pretends to know . cmake does not provide this functionality.
There have been specific cases where customers are given "custom builds" that are produced by buildbot. Those don't come with any information about the specific commit they're built from, which makes it nearly impossible to reliably identify what is actually being used.
My request is that as much of this information as possible be included, by default, in any builds done from our source. That means that someone will get access to this important information no matter where the package they're using has come from.
I want to know the name of the source tree, the name of the branch, the commit, how CMake is invoked, what CMake finds and ultimately uses for the build, etc. It may be some or all of that is not feasible for any number of reasons. But perhaps some of it is?