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
signature.asc
Description: This is a digitally signed message part
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
