google / benchmark

A microbenchmark support library
Apache License 2.0
8.69k stars 1.59k forks source link

[FR] Add a way to get the version of the library at compile-time #1591

Closed j-jorge closed 1 year ago

j-jorge commented 1 year ago

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 BENCHMARK_VERSION_MINOR >= 6
  int thread_index = state.thread_index();
#else
  int thread_index = state.thread_index;
#endif

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 :)

dmah42 commented 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.

j-jorge commented 1 year ago

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).

dmah42 commented 1 year ago

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).

j-jorge commented 1 year ago

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.

dmah42 commented 1 year ago

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.

j-jorge commented 1 year ago

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.

LebedevRI commented 1 year ago

We really should be advertising the version through some auto-generated header file, yes.