Re: [cmake-developers] Support for version suffixes

[Brad King]

On 03/27/2017 05:03 PM, Roger Leigh wrote:
> I'd like to bring this issue to your attention to canvas some feedback 
> regarding the use of version suffixes:
> 
>https://gitlab.kitware.com/cmake/cmake/issues/16716
> 
> The proposal linked above contains a much more detailed rationale and 
> suggested implementation strategy.  I'd be very happy to hear any 
> thoughts anyone has regarding this either on the above issue, or here.

Thanks for starting this thread.  I agree it would be nice to do more
general version comparisons.  However, I think more design work is
needed first.

Currently we have:

* cmSystemTools::VersionCompare compares leading unsigned integer
  components separated by `.` and ignores suffixes.  This is used
  by VERSION_LESS and such.

* cmSystemTools::strverscmp implements the strverscmp(3) function.
  This will happen to include suffixes in the version comparison due
  to a very clever definition of the comparison function, but it does
  not specifically treat suffixes as special.  It is also compatible
  with cmSystemTools::VersionCompare unless an integer component has
  leading zeros.  It is used by `CMAKE_FIND_PACKAGE_SORT_ORDER`, but
  otherwise we have no way to access it from the CMake language.

There are several version comparison conventions out there that interpret
suffixes in some way.  For example, PEP 440 [1].  I'd like to see a
summary of such schemes that are widely used.

Since CMake code often ends up comparing versions of other projects,
we may even need to implement several comparison functions and provide
a more general interface to specify which one to use for a given check.

Thanks,
-Brad


[1] https://www.python.org/dev/peps/pep-0440/#version-scheme

-- 

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-developers

Re: [cmake-developers] Support for version suffixes

[Brad King]

On 03/28/2017 04:07 AM, Jean-Michaël Celerier wrote:
> I remember asking for the same thing a few weeks ago on IRC because of
> a small behaviour change in cmake 3.8.0 rc2 that I wanted to put behind
> an if(version_less).

For reference, this was also proposed in issue 16656 [1].  The problem
is that 3.8.0-rc1 must not compare as less than 3.8.0 or the release
candidate will not satisfy `cmake_minimum_required(VERSION 3.8.0)`.
We want the release candidates to behave for projects as if they were
the final release in order to fully test them as such.  Users running
a release candidate should always be running the latest candidate.
Once the final release for a given version of CMake is out, none of its
corresponding release candidates should be used anymore.  Projects should
write their code under this assumption.

If a project has trouble with a specific release candidate then it can
use `if(MATCHES)` or another string-based approach to reject that
specific release candidate version, just as it might do if there were
a problem with a final release version of CMake.

-Brad


[1] https://gitlab.kitware.com/cmake/cmake/issues/16656

-- 

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-developers

Re: [cmake-developers] Support for version suffixes

[Daniel Pfeifer]

On Mon, Mar 27, 2017 at 11:03 PM, Roger Leigh  wrote:

> Hi folks,
>
> I'd like to bring this issue to your attention to canvas some feedback
> regarding the use of version suffixes:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16716
>
> This is basically a proposal to allow an optional version suffix like
> "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak
> pattern, for better interoperability with systems and software releases
> already using such suffixes, and also to permit the use of such suffixes by
> CMake projects for their own purposes.  A version suffix would be usable
> anywhere currently using 4 digit versions, with all the necessary
> functionality in CMake being updated to handle this.
>
> The proposal linked above contains a much more detailed rationale and
> suggested implementation strategy.  I'd be very happy to hear any thoughts
> anyone has regarding this either on the above issue, or here.
>

Hi Roger,

Thanks for starting this discussion!

I started a prototype for a PKGCONF mode for find_package in addition to
CONFIG and PACKAGE. In this mode, CMake parses .pc files and creates one
imported target per file where values from the .pc file are set as target
properties. It works pretty well and does not rely on pkg-config. To be
compatible with pkg-config, I needed to extend
`cmSystemTools::VersionCompare`, because pkg-config uses RPM version
comparison. This however breaks current tests because 1.2 != 1.2.0 in the
RPM version comparison.

It might be necessary to provide several version comparison algorithms like
Debian, RPM, Semver.
Also splitting the version string into components may depend on the
versioning scheme. Given OpenSSL version 1.0.2g, is that patch 2 suffix g,
or rather patch 2g?

Cheers, Daniel
-- 

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-developers

Re: [cmake-developers] Support for version suffixes

[Jean-Michaël Celerier]

I remember asking for the same thing a few weeks ago on IRC because of a
small behaviour change in cmake 3.8.0 rc2 that I wanted to put behind an
if(version_less).

Alphanumeric ordering would certainly work for most projects : alpha < beta
< rc. (I generally use a0, a1, a2... b0, b1, b2...)

Best
Jean-Michaël

On Mon, Mar 27, 2017 at 11:03 PM, Roger Leigh  wrote:

> Hi folks,
>
> I'd like to bring this issue to your attention to canvas some feedback
> regarding the use of version suffixes:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/16716
>
> This is basically a proposal to allow an optional version suffix like
> "-rc3", "-beta1" etc. in addition to the existing major.minor.patch.tweak
> pattern, for better interoperability with systems and software releases
> already using such suffixes, and also to permit the use of such suffixes by
> CMake projects for their own purposes.  A version suffix would be usable
> anywhere currently using 4 digit versions, with all the necessary
> functionality in CMake being updated to handle this.
>
> The proposal linked above contains a much more detailed rationale and
> suggested implementation strategy.  I'd be very happy to hear any thoughts
> anyone has regarding this either on the above issue, or here.
>
>
> Thanks all,
> Roger
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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-developers

[cmake-developers] Support for version suffixes

[Roger Leigh]

Hi folks,

I'd like to bring this issue to your attention to canvas some feedback 
regarding the use of version suffixes:


  https://gitlab.kitware.com/cmake/cmake/issues/16716

This is basically a proposal to allow an optional version suffix like 
"-rc3", "-beta1" etc. in addition to the existing 
major.minor.patch.tweak pattern, for better interoperability with 
systems and software releases already using such suffixes, and also to 
permit the use of such suffixes by CMake projects for their own 
purposes.  A version suffix would be usable anywhere currently using 4 
digit versions, with all the necessary functionality in CMake being 
updated to handle this.


The proposal linked above contains a much more detailed rationale and 
suggested implementation strategy.  I'd be very happy to hear any 
thoughts anyone has regarding this either on the above issue, or here.



Thanks all,
Roger
--

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-developers