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

[Philip Van Hoof]

On Mon, 2018-08-06 at 21:54 +0200, Hendrik Sattler wrote:

Hello Hendrik,

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

Right, I got a similar remark from the meson people. And I guess people
who are used to qmake will probably also rightfully wonder about this.

The reason is that I wanted to create four examples with identical
method of doing versioning, and that I wanted to refer to the autotools
mythbusters and official libtool documentation for the time being.

	For the time being until there is a sort of community consensus
(crossing multiple popular build environments), and that this gets
documented somewhat 'officially'. Right now, GNU kinda sets the de
facto standard and GNU (fortunately or unfortunately) utilizes libtool
and autotools (a lot). (Please don't read that as me saying that's a
good thing, as I'm not saying that).

I did however tried to make it easy to change the variable fabrication
at the root of the projects (the cmake-example/CMakeLists.txt).

For the cmake example you could take these (which admittedly are not
necessarily easy to understand, but, documented):

set(CMAKE_EXAMPLE_CURRENT_VERSION 3)
set(CMAKE_EXAMPLE_REVISION_VERSION 0)
set(CMAKE_EXAMPLE_AGE_VERSION 1)

math(EXPR CMAKE_EXAMPLE_SOVERSION "${CMAKE_EXAMPLE_CURRENT_VERSION} -
      ${CMAKE_EXAMPLE_AGE_VERSION}")

set(CMAKE_EXAMPLE_VERSION
  ${CMAKE_EXAMPLE_SOVERSION}.
    ${CMAKE_EXAMPLE_AGE_VERSION}.
    ${CMAKE_EXAMPLE_REVISION_VERSION})


And replace them with these (or something like these):

set(CMAKE_EXAMPLE_SOVERSION "2")
set(CMAKE_EXAMPLE_VERSION "2.1.0")

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

nod.

However. I'm not sure about trying to explain different versioning
style for equivalent examples (and in my examples I also include a
autotools one - unfortunately, or fortunately for people who are
converting from a autotools to a cmake, for example. Which is also
among the educational purposes of the examples).

I guess I could document it a little bit better in README.md ...

If people have suggestions? Just, however, let's try to keep it easy
for people coming from libtool-world. A lot of people do.

> The difficult thing is to realize the need for such a change. But
> there are tools that can help.

nod. I tried to explain the necessity in README.md.

I think it would be helpful to mention the tools, though. Suggestions
are welcome.

Thanks,

Kind regards,

Philip Van Hoof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://cmake.org/pipermail/cmake/attachments/20180806/f58f9797/attachment-0001.sig>