On Tue, Feb 03, 2015 at 04:38:15PM +0000, Ian Campbell wrote:
On Tue, 2015-02-03 at 10:58 -0500, Kevin O'Connor wrote:
On Tue, Feb 03, 2015 at 01:23:53PM +0100, Olaf Hering wrote:
The timestamp and hostname carries no value for the default build. If its really required in special environment, or if someone is emotionally attached to such strings, it is is handled by existing logic a few lines above: provide your own .version file
Once this patch is applied it is possible to get reproducible builds of Xens hvmloader.
I've found the version information to be quite helpful when we get trouble reports - it helps indicate what was being run and who built the code (eg, distribution or local). During development cycles, it helps verify that test runs are executed with the expected code.
What breaks if the version changes?
It should be possible to force a static version with "make VERSION='xyz'", but I'd ask that that not be done for production builds as it makes handling trouble reports harder.
Olaf posted some similar patches against Xen and it was suggested that using the git HEAD time and/or "git describe" would help.
We could probably arrange to do this when building SeaBIOS as part of Xen, or for tarball rather than git builds use the Xen release version?
SeaBIOS uses "git describe" as part of its version string today, and for SeaBIOS tar releases we embed a ".version" file with the release info (see scripts/buildversion.sh and scripts/tarball.sh for details).
Even with this, the build timestamp is still useful during development cycles (when the head may be dirty). And the hostname/timestamp are useful as a way of backtracking to the gcc/binutils environment on trouble reports even from official releases.
-Kevin