When writing libraries with CMake, you need to set a couple of properties, especially the VERSION and SOVERSION properties. For library libbar, it could look like:
|
1 2 |
set_property(TARGET bar PROPERTY VERSION "0.0.0") set_property(TARGET bar PROPERTY SOVERSION 0 ) |
This will give you a libbar.so => libbar.so.0 => libbar.so.0.0.0 symlink chain with a SONAME of libbar.so.0 encoded into the library.
The SOVERSION target property controls the number in the middle part of the symlink chain as well as the numeric part of the SONAME encoded into the library. The VERSION target property controls the last part of the last element of the symlink chain
This also means that the first part of VERSION should match what you put in SOVERSION to avoid surprises for others and for the future you.
Both these properties control “Technical parts” and should be looked at from a technical perspective. They should not be used for the ‘version of the software’, but purely for the technical versioning of the library.
In the kdeexamples git repository, it is handled like this:
|
1 2 3 4 |
set(BAR_VERSION_MAJOR 1) set(BAR_VERSION_MINOR 2) set(BAR_VERSION_PATCH 3) set(BAR_VERSION ${BAR_VERSION_MAJOR}.${BAR_VERSION_MINOR}.${BAR_VERSION_PATCH} ) |
And a bit later:
|
1 2 |
set_target_properties(bar PROPERTIES VERSION ${BAR_VERSION} SOVERSION ${BAR_VERSION_MAJOR} ) |
which is a fine way to ensure that things actually matches.
Oh. And these components is not something that should be inherited from other external projects.
So people, please be careful to use these correct.
The first example could’ve been better with a version number such as 1.2.3 rather than 0.0.0.
Re: “Both these properties control “Technical parts” and should be looked at from a technical perspective. They should not be used for the ‘version of the software’, but purely for the technical versioning of the library.”:
The first is true, but the latter is a matter of opinion. Personally I think it is unnecessarily confusing for libraries to have two separate versions, and much more sensible to simply use the same version. That way, the compatibility situation is clear from the library version, without having to dig around for the “other version” to see what the actual library version is. In particular, a changed major version means the library is not compatible with previous versions. This meshes well with packaging and makes everyone’s lives easier.
“Marketing-driven versioning” doesn’t makes much sense for libraries (which have a technically meaningful version), and should be restricted to apps.
No. It is not a matter of opinion. Having a libfoo.so > libfoo.so.0 > libfoo.so.4.3.1 chain is just confusing and bad and going to bother the future you (when you reach SONAME 4).