Re: [CMake] Changes to cmake_minimum_required() for 3.12

2018-07-02 Thread Johannes Zarl-Zierl 
Hi,

Just giving my 2 cents:
If the preferred solution is the "POLICY_NEW_UNTIL" wording, then why not make 
this accepted as well? This way, you can deprecate the backwards-compatible 
version in a few years and remove it some time thereafter. In the end, you'll 
get a cleaner solution...

Cheers,
  Johannes


On Montag, 2. Juli 2018 08:43:57 CEST Craig Scott wrote:
> On Mon, Jul 2, 2018 at 4:04 AM, Alan W. Irwin 
> 
> wrote:
> > On 2018-07-01 08:12+1000 Craig Scott wrote:
> > 
> > Older CMake versions
> > 
> >> will see the extra dots as being version component separators and will
> >> end
> >> up effectively ignoring the max part.
> > 
> > This explanation of how "..." will be interpreted by older CMake
> > versions makes sense, but it wasn't obvious to me without that
> > explanation.  And I suspect other build-system developers/maintainers
> > would also benefit from the explanation.  Therefore, please explicitly
> > include the above explanation in the latest documentation of both the
> > cmake_minimum_required and cmake_policy commands.
> 
> I've updated the merge request to incorporate this feedback.
> 
> https://gitlab.kitware.com/cmake/cmake/merge_requests/2180



-- 
Johannes Zarl-Zierl
Information management

JOHANNES KEPLER UNIVERSITY LINZ
Altenberger Straße 69
4040 Linz, Austria
P +43 732 2468 3898
johannes.zarl-zi...@jku.at
www.jku.at
-- 

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] Changes to cmake_minimum_required() for 3.12

2018-07-01 Thread Craig Scott 
On Mon, Jul 2, 2018 at 4:04 AM, Alan W. Irwin 
wrote:

> On 2018-07-01 08:12+1000 Craig Scott wrote:
>
> Older CMake versions
>> will see the extra dots as being version component separators and will end
>> up effectively ignoring the max part.
>>
>
> This explanation of how "..." will be interpreted by older CMake
> versions makes sense, but it wasn't obvious to me without that
> explanation.  And I suspect other build-system developers/maintainers
> would also benefit from the explanation.  Therefore, please explicitly
> include the above explanation in the latest documentation of both the
> cmake_minimum_required and cmake_policy commands.
>

I've updated the merge request to incorporate this feedback.

https://gitlab.kitware.com/cmake/cmake/merge_requests/2180

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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] Changes to cmake_minimum_required() for 3.12

2018-07-01 Thread Hendrik Sattler 
Thanks for the link.
The backwards compatibility is something worth mentioning in the release notes, 
so that people can use it right away.


Am 1. Juli 2018 00:12:19 MESZ schrieb Craig Scott :
>(Subject changed to be specific to this discussion)
>
>On Sat, Jun 30, 2018 at 3:13 PM, Hendrik Sattler
>
>wrote:
>
>> It would actually make even more sense to rename
>cmake_minimum_required()
>> to cmake_version_required() with the new syntax or something similar.
>Users
>> of the old function cannot use the new syntax in older cmake versions
>and
>> the old name does not actually fit the new functionality.
>>
>
>Actually older versions can use the new syntax and this is indeed the
>specific reason why the new syntax is the way it is. Older CMake
>versions
>will see the extra dots as being version component separators and will
>end
>up effectively ignoring the max part. The nett result is that older
>versions will continue to treat the min version as the policy setting
>just
>like they have been to date. Newer versions of CMake will be able to
>take
>advantage of the extra information provided by the max part to allow
>newer
>policies to be enforced.
>
>Regarding the renaming, a very similar discussion took place in the
>merge
>request itself, so I'll refer you to there for details:
>
>https://gitlab.kitware.com/cmake/cmake/merge_requests/1864#note_389157
>
>
>
>
>>
>> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" <
>> ir...@beluga.phys.uvic.ca>:
>> >On 2018-06-29 14:46-0400 Robert Maynard wrote:
>> >[...]
>> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
>> >>  commands now accept a version range using the form
>> >>  "[...]". The "" version is required but policies
>are
>> >>  set based on the "" version.  This allows projects to
>specify a
>> >>  range of versions for which they have been updated and avoid
>> >>  explicit policy settings.
>> >[...]
>> >
>> >I suggest the following change to the above description:
>> >
>> >but policies are set based on the "" version.
>> >
>> >==>
>> >
>> >but policies are set based on the minimum of the running CMake and
>> >"" versions.
>> >
>> >I prefer the latter because it immediately answers the question
>implied
>> >by the former, i.e.,
>> >what happens if the running version is less than max?
>>
>
>Seems reasonable. I've created a MR with a slight tweak to your wording
>for
>this here .
>
>-- 
>Craig Scott
>Melbourne, Australia
>https://crascit.com
-- 

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] Changes to cmake_minimum_required() for 3.12

2018-06-30 Thread Craig Scott 
(Subject changed to be specific to this discussion)

On Sat, Jun 30, 2018 at 3:13 PM, Hendrik Sattler 
wrote:

> It would actually make even more sense to rename cmake_minimum_required()
> to cmake_version_required() with the new syntax or something similar. Users
> of the old function cannot use the new syntax in older cmake versions and
> the old name does not actually fit the new functionality.
>

Actually older versions can use the new syntax and this is indeed the
specific reason why the new syntax is the way it is. Older CMake versions
will see the extra dots as being version component separators and will end
up effectively ignoring the max part. The nett result is that older
versions will continue to treat the min version as the policy setting just
like they have been to date. Newer versions of CMake will be able to take
advantage of the extra information provided by the max part to allow newer
policies to be enforced.

Regarding the renaming, a very similar discussion took place in the merge
request itself, so I'll refer you to there for details:

https://gitlab.kitware.com/cmake/cmake/merge_requests/1864#note_389157




>
> Am 30. Juni 2018 00:05:25 MESZ schrieb "Alan W. Irwin" <
> ir...@beluga.phys.uvic.ca>:
> >On 2018-06-29 14:46-0400 Robert Maynard wrote:
> >[...]
> >> * The "cmake_minimum_required()" and "cmake_policy(VERSION)"
> >>  commands now accept a version range using the form
> >>  "[...]". The "" version is required but policies are
> >>  set based on the "" version.  This allows projects to specify a
> >>  range of versions for which they have been updated and avoid
> >>  explicit policy settings.
> >[...]
> >
> >I suggest the following change to the above description:
> >
> >but policies are set based on the "" version.
> >
> >==>
> >
> >but policies are set based on the minimum of the running CMake and
> >"" versions.
> >
> >I prefer the latter because it immediately answers the question implied
> >by the former, i.e.,
> >what happens if the running version is less than max?
>

Seems reasonable. I've created a MR with a slight tweak to your wording for
this here .

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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