[CMake] How to build fully correctly versioned shared object files with cmake

[Hendrik Sattler]

Am 6. August 2018 22:29:21 MESZ schrieb Alexander Neundorf <neundorf at kde.org>:
>On 2018 M08 6, Mon 21:54:33 CEST Hendrik Sattler wrote:
>> Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof 
><philip at codeminded.be>:
>> >Hello everyone,
>> >
>> >I noticed that it sometimes happens that I find a package for a
>shared
>> >object file(s) (or DLLs, on platforms like Windows) that have a
>build
>> >set up using cmake, that doesn't set everything that should be set.
>> >
>> >Usually as packagers of various popular open source softwares
>correct
>> >enthusiasts' attempts at understanding the sometimes bizarre
>> >complexities of for example autotools, but (although it's all less
>> >complicated) also cmake, it ends up somewhat right. Somewhat. I
>noticed
>> >that especially in corporate world, things tend to go spectacularly
>> >wrong. Almost without exception.
>> >
>> >In particular am I concerned about ABI versioning of shared object
>> >files so that they are easy to package and distribute by various
>> >operating systems (like, among others, Linux distributions). But
>also
>> >API versioning of development files (compiler header files and pkg-
>> >config) and installing to the right installation paths.
>> >
>> >I wanted to invite the community to scrutinize some equivalent
>examples
>> >that I made for autotools (with libtool), qmake, cmake and meson.
>> >
>> >https://github.com/pvanhoof/dir-examples/
>> >
>> >In particular I wanted to invite the cmake community to take a look
>at
>> >this example:
>> >
>> >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
>> >
>> >The idea is that the examples are as correct as possible. That means
>> >the examples should simple and educational. Easing (some amount) of
>> >platform independence (ie. supporting Windows) and packaging.
>> 
>> Is there ANY reason to use libtool library versioning? It might
>surprise
>> people but it really is not any kind of standard.
>> 
>> Just change the SOVERSION when you make incompatible ABI changes and
>a
>> normal library VERSION. There's really not more to it, especially
>nothing
>> like the sick results that libtool produces, sometimes.
>
>I agree.
>I would recommend
>Major version  = SO version, increase it if you break ABI compatibility
>Minor version: increase it if you add ABI compatible features
>Patch version: increase it for bug fix releases.

Right. See http://semver.org

A  tool to check is e.g. the abi compliance checker.

It may be worth to mention that project version and library version may differ but that it also might confuse people.