[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] Configuration packages & versioning for parallel installations
From: Alex Turbov <i.zaufi () gmail ! com>
Date: 2017-09-06 22:17:01
Message-ID: CANktQtueMEFUaaWugE1rtzvGE2Om1CVqUoUaYJxOsARQ3Fb0MA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
On Thu, Sep 7, 2017 at 12:26 AM, Robert Dailey <rcdailey.lists@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
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<br><br><br><div class="gmail_extra"><br><div \
class="gmail_quote">On Thu, Sep 7, 2017 at 12:26 AM, Robert Dailey <span \
dir="ltr"><<a href="mailto:rcdailey.lists@gmail.com" \
target="_blank">rcdailey.lists@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">First obvious question is: Should this even be a concern? \
</blockquote><div><br></div><div>Yes, definitely!<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">The<br> cmake-packages documentation doesn't really touch \
on versioning, but<br> there are a couple of concerns I see when you want users to be \
able to<br> install (with CMake) multiple versions of the same library<br>
side-by-side:<br></blockquote><div><br></div><div>that is quite usual practice (at \
least for me) to have multiple versions installed and (try) link my package w/ \
'em.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
1. The library files have to use VERSION or SOVERSION properties to<br>
affect their name (this needs to be consistent on all \
platforms)<br></blockquote><div><br></div><div>I use versioned static libraries on \
all platforms (*NIX/Linux and Windows) and dynamic in Windows only.</div><div>For \
linux dynamic libraries use traditional format `libblah.so.X.Y.Z`. (yea w/ VERSION \
and SOVERSION properties)<br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 2. Debug \
configurations should alter the name of the library (to<br> support \
multi-configuration generators like Visual Studio, for the<br> most part, but also \
useful to single-configuration generators)<br></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> 3. Header file installation: How \
do you do versioning? How do you have<br> a foo.h that is version 1.0, and a foo.h \
that is version 2.0? Does<br> this even make \
sense?<br></blockquote><div><br></div><div>Header files installed into \
`/usr/include/package-X.Y.Z/`, and exported targets always know this (and set the \
corresponding INTERFACE properties)<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
One approach I've taken so far is:<br>
<br>
1. CMake scripts like config scripts and exported target scripts go<br>
under "share/libraryname-1.0/cmake"<br></blockquote><div><br></div><div>yep, \
it would work... for linux personally I prefer \
`/usr/lib/cmake/package-X.Y.Z/`<br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 2. Library \
names follow a format like "libfoo-1.0.0", or<br> \
"libfoo-1.0.0-debug" for debug versions of that same library.<br> \
<br></blockquote><div><br></div><div>Personally I use semantic versioning (<a \
href="http://semver.org">http://semver.org</a>) and 'SameMajor' compatibility \
option work pretty fine for me even w/ dozen of dependencies...<br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I have no answer for include files.<br>
--<br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" \
target="_blank">www.kitware.com</a><br> <br>
Please keep messages on-topic and check the CMake FAQ at: <a \
href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" \
target="_blank">http://www.cmake.org/Wiki/<wbr>CMake_FAQ</a><br> <br>
Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:<br> <br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" \
target="_blank">http://cmake.org/cmake/help/<wbr>support.html</a><br> CMake \
Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" \
target="_blank">http://cmake.org/cmake/help/<wbr>consulting.html</a><br> CMake \
Training Courses: <a href="http://cmake.org/cmake/help/training.html" \
rel="noreferrer" target="_blank">http://cmake.org/cmake/help/<wbr>training.html</a><br>
<br>
Visit other Kitware open-source projects at <a \
href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" \
target="_blank">http://www.kitware.com/<wbr>opensource/opensource.html</a><br> <br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" \
target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/cmake</a><br> \
</blockquote></div><br></div></div>
--
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic