Closed j-jorge closed 1 year ago
why do you need to build against both? this would help me understand how often this issue is likely to come up.
The libraries on my dev computer are a bit more recent than the ones on our CI. On the CI we use the reference build environment of the company, where upgrading something is quite slow (many discussions and validation steps, which is normal), but I try to keep my tools recent in day to day development to keep the code in good shape for when the reference environment is updated (it makes the process smoother).
we could add something to benchmark.h
. we already include it in the __init__.py
for the python bindings, and in the cmake config, when we do a release. it wouldn't be a huge stretch to update it in one more place.
we could automate the creation of a version header from cmake but it's a bit of a pain and it means another header being distributed which i'd like to avoid (or we change the benchmark.h to be generated entirely just for this one field which again is unnecessary complexity).
If I could extract it from whatever CMake's find_package(benchmark)
finds, it would be enough. A BENCHMARK_VERSION
CMake variable maybe? I don't know if there is already a feature like this in CMake's find_package()
, as it seems quite a general feature and CMake already checks the versions by itself.
https://stackoverflow.com/questions/49531044/get-cmake-project-version-added-by-add-subdirectory perhaps could help? we set the version using project
and make sure it's set before cutting a new release.
Nevermind, I have everything I need with CMake. From the documentation of find_package()
:
If the version is acceptable the following variables are set:
<PackageName>_VERSION
- Full provided version string
It seems that I failed to read correctly :) Sorry for the noise.
We really should be advertising the version through some auto-generated header file, yes.
Hello,
I have to build my benchmark against Benchmark versions 1.5 and a version after 1.6. This causes compilation issues on multi-threaded benchmarks when I rely on
benchmark::State::thread_index
. Indeed, in version 1.5 this member was a variable, but in 1.6 it became a function.I which I could rely on some compile-time information to discriminate between these two implementations, for example with preprocessor definition:
If you have any other solution I would be interested too (something I missed?), especially since the introduction of a preprocessor definition in future versions would not solve the 1.5/1.6 discrimination. The current solution I use is a weird meta-programming implementation based on the existence of
benchmark::StatisticUnit
(introduced in 1.6).Thanks :)