On 11.11.2016 22:36 Alexander Neundorf wrote:
On Wednesday 09 November 2016 09:22:24 Nils Gladitz wrote:
...
Policy warnings are intended to encourage you to switch to new
behaviours since the old ones are deprecated.
In actively maintained projects they are not meant to be suppressed.
I
On 11.11.2016 22:36 Alexander Neundorf wrote:
You could have a look at the major distributions and what they ship.
Thanks for your comments.
We do not only want to support the major distributions but also (maybe
proprietary) cross compilation tools. That's why we still support
On Wednesday 09 November 2016 09:22:24 Nils Gladitz wrote:
...
> You said you are not forcing your users to upgrade by setting a policy
> to OLD.
> Which implied that not setting the policy to OLD would force your users
> to upgrade ... which it doesn't.
>
> >> In fact all that setting it to OLD
On Wednesday 09 November 2016 00:47:39 Albrecht Schlosser wrote:
> On 08.11.2016 23:01 Nils Gladitz wrote:
> > On 08.11.2016 20:26, Albrecht Schlosser wrote:
> >> I'm a developer of a public GUI library (FLTK). In this position you
> >> don't know anything about the availability of CMake versions
On 11/09/2016 09:06 PM, Ruslan Baratov wrote:
So why the project in the middle of the migration process is not a valid
case? It is maintained but the exact migration step is paused, but I
have an intention to improve the code in future. Anyway even if the
project is no longer maintained, then
On 09-Nov-16 23:00, Nils Gladitz wrote:
> On 09.11.2016 15:52, Ruslan Baratov wrote:
>> Can you show the real code? The code that in your opinion doesn't
>> violate the "right way of policy usage"?
>
> It is not a question about code. It is a question about context and
> use case.
You just said
On 09.11.2016 15:52, Ruslan Baratov wrote:
Can you show the real code? The code that in your opinion doesn't
violate the "right way of policy usage"?
It is not a question about code. It is a question about context and use
case.
Valid context as the documentation states would e.g. be a
Can you show the real code? The code that in your opinion doesn't
violate the "right way of policy usage"?
On 09-Nov-16 22:14, Nils Gladitz wrote:
> On 09.11.2016 14:57, Ruslan Baratov wrote:
>>
>> Again policies are not meant to be feature toggles.
>> You can do a lot of things and there may be
On 09.11.2016 14:57, Ruslan Baratov wrote:
Again policies are not meant to be feature toggles.
You can do a lot of things and there may be valid use cases but in
general policies are not meant to be used this way.
This is made explicit in CMake's documentation on policies.
They exist to
On 09-Nov-16 19:51, Nils Gladitz wrote:
> On 09.11.2016 12:04, Ruslan Baratov wrote:
>> On 09-Nov-16 16:22, Nils Gladitz wrote:
>>> On 09.11.2016 04:29, Ruslan Baratov wrote:
On 08-Nov-16 23:33, Nils Gladitz wrote:
> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>
>> Except it's
Oops, totally forgot to mention the crux: I happened to be the guy who
apparently was the first to start using continue() - so by the time my
college got to me, we quickly found out the issue. But before the college
hit the problem, I didn't have the vaguest clue that I was typing code that
would
+1 for me too - sometime ago a college of mine spend quite some time to
figure why he couldn't bootstrap our application - turns out he was using
an (old) CMake version which didn't know about the 'continue' command. The
error-messages coming out of CMake sometimes help, but more often don't
On 09.11.2016 12:04, Ruslan Baratov wrote:
On 09-Nov-16 16:22, Nils Gladitz wrote:
On 09.11.2016 04:29, Ruslan Baratov wrote:
On 08-Nov-16 23:33, Nils Gladitz wrote:
On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
Except it's exactly opposite :) `cmake_minimum_required` is about new
On 09-Nov-16 16:22, Nils Gladitz wrote:
> On 09.11.2016 03:47, Ruslan Baratov wrote:
>> On 09-Nov-16 06:01, Nils Gladitz wrote:
>>> I think the git tag creation dates should roughly equate release dates:
>>> https://cmake.org/gitweb?p=cmake.git;a=tags
>> What about the future releases? There
On 09-Nov-16 16:22, Nils Gladitz wrote:
> On 09.11.2016 04:29, Ruslan Baratov wrote:
>> On 08-Nov-16 23:33, Nils Gladitz wrote:
>>> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>>>
Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is
On 09.11.2016 03:47, Ruslan Baratov wrote:
On 09-Nov-16 06:01, Nils Gladitz wrote:
I think the git tag creation dates should roughly equate release dates:
https://cmake.org/gitweb?p=cmake.git;a=tags
What about the future releases? There was a page
https://cmake.org/Bug/changelog_page.php
On 09.11.2016 04:29, Ruslan Baratov wrote:
On 08-Nov-16 23:33, Nils Gladitz wrote:
On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior.
I don't agree and you can not separate
On 08-Nov-16 23:33, Nils Gladitz wrote:
> On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
>
>> On 08-Nov-16 22:22, Nils Gladitz wrote:
>>> Strictly speaking cmake_minimum_required(VERSION) is not about command
>>> availability but rather about behavior (cmake policies).
>> Except it's exactly
On 09-Nov-16 06:01, Nils Gladitz wrote:
> On 08.11.2016 20:26, Albrecht Schlosser wrote:
>
>>
>> I'd like to have a list of release dates (I'm not sure if there is
>> one) as well as the exact version a feature was introduced to write
>> CMakeLists.txt files that run on really old CMake versions.
On 08.11.2016 23:01 Nils Gladitz wrote:
On 08.11.2016 20:26, Albrecht Schlosser wrote:
I'm a developer of a public GUI library (FLTK). In this position you
don't know anything about the availability of CMake versions on your
target platforms. Our intention is to keep cmake_minimum_required()
On 08.11.2016 22:23 Eric Noulard wrote:
2016-11-08 20:26 GMT+01:00 Albrecht Schlosser <...>:
I'd also like such an addition to the documentation for reasons
discussed below.
I think the need is recognized by most CMake user but...
okay...
Strictly speaking
On 08.11.2016 20:26, Albrecht Schlosser wrote:
On 08.11.2016 15:22 Nils Gladitz wrote:
Strictly speaking cmake_minimum_required(VERSION) is not about command
availability but rather about behavior (cmake policies).
[...]
I'd start by requesting the highest possible version I could justify
Rather than trying to do everything, perhaps there's value in tackling this
in stages. At a high level, simply knowing in which CMake version a
particular command, property, variable or module was added is a good start.
>From there, if a command, etc. gained new options, then a note could be
added
2016-11-08 20:26 GMT+01:00 Albrecht Schlosser :
> On 08.11.2016 15:22 Nils Gladitz wrote:
>
>> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:
>>
>> But how do you know which version to declare on cmake_minimum_required?
>>> If this feature will be added it won't be far
On 08.11.2016 15:22 Nils Gladitz wrote:
On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:
But how do you know which version to declare on cmake_minimum_required?
If this feature will be added it won't be far from writing a script
that scans the commands you use and outputs the first appropriate
On 11/08/2016 04:17 PM, Ruslan Baratov wrote:
On 08-Nov-16 22:22, Nils Gladitz wrote:
Strictly speaking cmake_minimum_required(VERSION) is not about command
availability but rather about behavior (cmake policies).
Except it's exactly opposite :) `cmake_minimum_required` is about new
On 08-Nov-16 22:11, Dvir Yitzchaki wrote:
> But how do you know which version to declare on cmake_minimum_required?
I do hit this too. This would be a very useful feature. Sometimes I have
to manually "scan" the docs to figure out some simple facts about newly
introduces variables/commands.
On
On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:
But how do you know which version to declare on cmake_minimum_required?
If this feature will be added it won't be far from writing a script that scans
the commands you use and outputs the first appropriate version.
Strictly speaking
...@cmake.org] On Behalf Of Nils Gladitz
Sent: Tuesday, November 08, 2016 3:37 PM
To: Louis-Paul CORDIER <lp.cord...@dynamixyz.com>; Cmake Mailing List
<cmake@cmake.org>
Subject: Re: [CMake] Adding Cmake version in online documentation
On 11/08/2016 10:57 AM, Louis-Paul CORDIER
On 11/08/2016 10:57 AM, Louis-Paul CORDIER wrote:
Hi,
This is a feature proposal for the documentation. Cmake is making use
of cmake_minimum_required() command, that is very useful.
Unfortunately it is very hard to identify commands that will work
without browsing all version of cmake
+1
--
Mike Jackson [mike.jack...@bluequartz.net]
Louis-Paul CORDIER wrote:
Hi,
This is a feature proposal for the documentation. Cmake is making use of
cmake_minimum_required() command, that is very useful. Unfortunately it
is very hard to identify commands that will work without browsing
Hi,
This is a feature proposal for the documentation. Cmake is making use of
cmake_minimum_required() command, that is very useful. Unfortunately it
is very hard to identify commands that will work without browsing all
version of cmake documentation for a given command.
That said, adding a
32 matches
Mail list logo