Repository navigation
build: add a build tag into the version for non-release builds #156
Description
Activity
9 remaining items
Is the slowdown happening even in incremental builds, or only after a make clean? If the former, we can add caching of the calculated tag so that it's only recalculated if HEAD is different than what it was when the tag was calculated. If the latter, I don't have a good solution for that, unfortunately, because we do need to calculate the tag somehow. The idea is not just to capture the date/time, but to allow easily comparing two builds and quickly inferring where they are on the git tree in relation to each other.
As for the version, we actually only have a Speedb version string, since this function is only used for outputting to the LOG file and the tools help text, so we don't really care about backward compatibility, and the format is <speedb-version> (<rocksdb-version>) (currently 2.1.0 (7.2.2)).
The slowdown happens every time.
time make -j 32 dbg
$DEBUG_LEVEL is 2
Makefile:178: Warning: Compiling in debug mode. Don't use the resulting binary in production
- GEN make_config.mk
make: Nothing to be done for `dbg'.
make -j 32 dbg 75.01s user 28.32s system 92% cpu 1:51.49 total
markrambacher@marks-mbp speedb % time make -j 32 dbg
$DEBUG_LEVEL is 2
Makefile:178: Warning: Compiling in debug mode. Don't use the resulting binary in production - GEN make_config.mk
make: Nothing to be done for `dbg'.
make -j 32 dbg 75.22s user 28.54s system 92% cpu 1:52.38 total
The tag that is generated is also kind of strange. It is meaningless to me:
#define SPDB_BUILD_TAG "(#merge-7.8+108)-(yuval/comp_precut2-squashed-10655+7)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+7)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+7)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+54)-(#merge-7.8+4)-(yuval/comp_precut2-squashed-10655+25)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+55)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+48)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+3)-(#merge-7.8+4)-(yuval/comp_precut2-squashed-10655+199)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+7)-(#merge-7.8+2)-(yuval/comp_precut2-squashed-10655+4)-(#merge-7.8+2)-(yuval/comp_precut2-squashed-10655+7)-(#merge-7.8+1)-(yuval/comp_precut2-squashed-10655+5)-(#merge-7.8+2)-(yuval/comp_precut2-squashed-10655+7)-(#merge-7.8+69)-(main+1)-(#merge-7.8+3)-(main+1)-(#merge-7.8+7)-(main+1)-(#merge-7.8+1)-(main+3)-(#merge-7.8+3)"
static const std::string speedb_build_tag = "speedb_build_tag:" SPDB_BUILD_TAG;
Woops. I just realised that you also correctly spotted the issue with the version string. I assumed that you meant the GetRocksBuildInfoAsString(), and that's indeed the only function that exists. However, the changes were indeed incorrectly applied to GetRocksVersionAsString() instead of GetSpeedbVersionAsString(). My bad. I opened #231 to track it and submitted #233 to to fix it. Thanks for catching this!
For various tasks (especially for the performance tests) we sometimes need to compare builds and tell how they are ordered in the git tree. The current version number is not enough because it's only changed on releases, and while the git hash uniquely identifies a build, it requires access to the git tree in order to find that information, and it becomes useless if the specific commit is later amended or deleted from the tree altogether.
Add an optional build tag to the version and allow setting it during the build (or at configuration time, if using CMake). If it's not set, use a script to calculate a build tag based on the git tree since the last release, falling back to a build tag of
?in case we aren't able to determine the git tree, which would basically mean that this isn't a release build, and that the git hash should be manually checked as we do today.