[CMake] Providing multiple different MAJOR API versions with write_basic_package_version_file
Hello, After Craig's very interesting presentation at CppCon 2019* I learned a bunch of new things which I of course immediately wanted to try out**. I read about the write_basic_package_version_file which is in CMakePackageConfigHelpers. Craig also mentioned in the presentation that you can have a so called API-version in the target's name. And that for example Qt does this (Qt5Core, which has the MAJOR number 5 in its target name). For my target name I prefer to have the API version after a dash, like how GLib and DBus packages do it: libglib-2.0.so.0.6200.1 on current Ubuntu, for example in /usr/lib/x86_64-linux-gnu. I wonder what that means for the property of write_basic_package_version_file. In the autotools and meson world, the usage of pkg-config files seems to indicate that the same filename naming scheme applies to the .pc file: /usr/lib/x86_64-linux-gnu/pkgconfig/glib-2.0.pc This allows me to distinguish between older MAJOR API versions of GLib and newer MAJOR API versions of it, using FindPkgConfig*** Supposedly something similar is possible with find_package's .cmake files as installed by write_basic_package_version_file? How do I provide a PackageNameConfigVersion.cmake for major version 1.0 and 2.0 (the equivalent of PackageName-1.0.pc and PackageName-2.0.pc in the pkgconfig directory)? Kind regards, Philip * https://www.youtube.com/watch?v=m0DwB4OvDXk ** https://github.com/pvanhoof/dir-examples/commit/523cab5edaff99acba037218d5b95227cb2487a9 *** https://cmake.org/cmake/help/v3.15/module/FindPkgConfig.html 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
Re: [CMake] How to build fully correctly versioned shared object files with cmake
Alexander Neundorf wrote: > On Mon, 2018-08-06 at 21:54 +0200, Hendrik Sattler wrote: > > 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. > > Alex Ok, I added this note to README.md, cmake, meson and qmake examples: # When you don't care about compatibility with libtool's -version-info, then you can take the following rules for VERSION in cmake, meson and qmake: # * SOVERSION = Major version # * Major 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. https://github.com/pvanhoof/dir-examples/commit/02a9a2d23ddf3627f87dd7a1af74b42603c4f890 (Because yes, you're right that libtool's -version-info is just pointlessly complicated and messy for people who don't need to care) 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
Re: [CMake] How to build fully correctly versioned shared object files with cmake
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
[CMake] How to build fully correctly versioned shared object files with cmake
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. ps. I don't think CC-ing a huge amount of mailing lists is necessarily a good idea. So feel free to forward to the appropriate people. ps. I attached no license to the examples yet. Perhaps I should attach one? My goal would be that as much entities could copy and use it. Including for, indeed, non-free purposes (as much as they want). 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
