Putting the build date in the executable is a practice that has no place
in these days, now that deterministic building is increasingly common.
Continues #7732 which did this for the GUI.
Drawback: The version string is no longer a valid git identifier.
For this reason the 'g' short hash prefix has been removed.
Exception: When building directly from a tag this behaves exactly like the previous behavior.
This allows formatting release versions with precision i.e. v0.9.2
This also allows arbitrary topicbranch names i.e. v0.9.1-glibc-compat
Don't define BUILD_DATE at all when no git version information
is available. `version.cpp` will then define it for us correctly
to the last commit date.
This has been fixed and broken many times over 0.9 history
(21cc8bd, ef1e984), please don't touch this code unless you plan
on testing all possible scenarios including gitian builds.
Fixes#3570.
When building from tarball (i.g. not from git source tree or when git
is not available) `genbuild.sh` write undefined $TIME to "build/build.h".
Even worse, when TIME is set in the environment then its value
is written instead of a date.
For me this change fixed FTBFS which I got because I had
TIME enviroment variable set with format for time(1) utility.
All client version information is moved to version.cpp, which optionally
(-DHAVE_BUILD_INFO) includes build.h. build.h is automatically generated
on supporting platforms via contrib/genbuild.sh, using git describe.
The git export-subst attribute is used to put the commit id statically
in version.cpp inside generated archives, and this value is used if no
build.h is present.
The gitian descriptors are modified to use git archive instead of a
copy, to create the src/ directory in the output. This way,
src/src/version.cpp will contain the static commit id. To prevent
gitian builds from getting the "-dirty" marker in their git-describe
generated identifiers, no touching of files or running sed on the
makefile is performed anymore. This does not seem to influence
determinism.
practicalswift