Use the full version as the SOVERSION

[musicinmybrain]

This assumes that ABI is likely to be broken any time, including in patch releases.

If this is a good assumption, then this change fixes #2340.

If it is strongly believed that patch releases won’t contain ABI-breaking changes, then something like this might make sense instead:

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -126,7 +126,7 @@ message(STATUS "Google Benchmark version: ${VERSION}, normalized to ${NORMALIZED
 
 # The version of the libraries
 set(GENERIC_LIB_VERSION ${NORMALIZED_VERSION})
-string(SUBSTRING ${NORMALIZED_VERSION} 0 1 GENERIC_LIB_SOVERSION)
+string(REGEX REPLACE "([^\\.]+\\.[^\\..]+).*" "\\1" GENERIC_LIB_SOVERSION ${NORMALIZED_VERSION})
 
 # Import our CMake modules
 include(AddCXXCompilerFlag)

[dmah42]

to confirm: for this project, the major and minor versions can introduce API breaking changes. we would only go to v2 if there was a significant reworking of the project (which is unlikely). given that, do we need this PR? what are the ramifications of the change?

[musicinmybrain]

to confirm: for this project, the major and minor versions can introduce API breaking changes. we would only go to v2 if there was a significant reworking of the project (which is unlikely). given that, do we need this PR? what are the ramifications of the change?

The SONAME version (CMake “SOVERSON”) is the shared library ABI (not API!) version, and it needs to change every time the shared library’s ABI does. The rules about this in C++ are pretty complicated, but https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B is a good overview of what constitutes an ABI-breaking change.

This is important in places like Linux distributions because even when the API remains compatible, an ABI break means that programs linked against the shared library need to be recompiled. Indicating this is the entire purpose of versioning the shared library with SOVERSION.

A good example of an API-compatible change that is not ABI-compatible is given in #2340, where a function with two parameters gained a third parameter with a default value. This is API-compatible, depending on your definition of API, because the compiler will implicitly use the default third parameter for existing code that calls the function with two parameters. However, executables that were already compiled using the headers for old version will actually call the function with two parameters, making no provisions to pass the default third parameter value (which didn’t exist at the time). Depending on calling convention, this might mean that the register that should have the third parameter in it has garbage instead, or perhaps it could lead to stack corruption.

If no measures are being taken to detect and avoid ABI breaks in patch releases, then the only honest thing to do is to bump the ABI version of every release, and the easiest way to do that is to use the entire version number.

[dmah42]

that works for me. is there a down side? i can't see one.

[LebedevRI]

I mean, we could add a CI job that would ensure that would ensure that soversion is bumped when needed.
But in reality, are there any packages that actually install their benchmarks?
Because that's really the only situation when this matters.
(They'd need to be recompiled when the distribution updates the benchmark package.)

[musicinmybrain]

that works for me. is there a down side? i can't see one.

In general, the downside of bumping the SONAME version too often is that it forces distributions and people in similar positions to do dependent package rebuilds and other breaking-change coordination unnecessarily, wasting time and resources. This is undesirable, but failing to bump the SONAME version when it should have been bumped is much worse.

But in reality, are there any packages that actually install their benchmarks? Because that's really the only situation when this matters. (They'd need to be recompiled when the distribution updates the benchmark package.)

There don’t seem to be any such packages in Fedora; google-benchmark is only a build-time dependency, and there aren’t any packages that would actually have to be rebuilt after an ABI-breaking update. Policy still requires us to pay attention to ABI breaks and not ship these updates in stable releases; after all, we don’t know what people have built on top of the distribution.

On the other hand, one would think that packages would not generally ship test code, but there are quite a few packages in Fedora that ship test suites, tools, or libraries built on top of gtest/gmock and do have to be rebuilt when the gtest package is updated. It’s not out of the question that someone might eventually ship something that links google-benchmark.

[LebedevRI]

<...>

(that matches my understanding, yes)