[CMake] Configuration packages & versioning for parallel installations

[Alex Turbov]

Hi,



On Thu, Sep 7, 2017 at 12:26 AM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> First obvious question is: Should this even be a concern?


Yes, definitely!


> The
> cmake-packages documentation doesn't really touch on versioning, but
> there are a couple of concerns I see when you want users to be able to
> install (with CMake) multiple versions of the same library
> side-by-side:
>

that is quite usual practice (at least for me) to have multiple versions
installed and (try) link my package w/ 'em.


>
> 1. The library files have to use VERSION or SOVERSION properties to
> affect their name (this needs to be consistent on all platforms)
>

I use versioned static libraries on all platforms (*NIX/Linux and Windows)
and dynamic in Windows only.
For linux dynamic libraries use traditional format `libblah.so.X.Y.Z`. (yea
w/ VERSION and SOVERSION properties)


> 2. Debug configurations should alter the name of the library (to
> support multi-configuration generators like Visual Studio, for the
> most part, but also useful to single-configuration generators)
>

I do it for Windows only... (just don't need it for linux, where I prefer a
single ocnifuration to be installed, just like most pakcages do in my
Gentoo).


> 3. Header file installation: How do you do versioning? How do you have
> a foo.h that is version 1.0, and a foo.h that is version 2.0? Does
> this even make sense?
>

Header files installed into `/usr/include/package-X.Y.Z/`, and exported
targets always know this (and set the corresponding INTERFACE properties)


>
> One approach I've taken so far is:
>
> 1. CMake scripts like config scripts and exported target scripts go
> under "share/libraryname-1.0/cmake"
>

yep, it would work... for linux personally I prefer
`/usr/lib/cmake/package-X.Y.Z/`


> 2. Library names follow a format like "libfoo-1.0.0", or
> "libfoo-1.0.0-debug" for debug versions of that same library.
>
>
Personally I use semantic versioning (http://semver.org) and 'SameMajor'
compatibility option work pretty fine for me even w/ dozen of
dependencies...


> I have no answer for include files.
> --
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170907/62ca97fd/attachment.html>