Configuration packages & versioning for parallel installations

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Configuration packages & versioning for parallel installations

Robert Dailey-2
First obvious question is: Should this even be a concern? 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:

1. The library files have to use VERSION or SOVERSION properties to
affect their name (this needs to be consistent on all platforms)
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)
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?

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"
2. Library names follow a format like "libfoo-1.0.0", or
"libfoo-1.0.0-debug" for debug versions of that same library.

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
Reply | Threaded
Open this post in threaded view
|

Re: Configuration packages & versioning for parallel installations

Alex Turbov
Hi,



On Thu, Sep 7, 2017 at 12:26 AM, Robert Dailey <[hidden email]> 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


--

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