On 09/22/2014 10:07 AM, Brad King wrote:
Or, one could add the explicit PUSH/POP in modules, e.g.
cmake_policy(PUSH)
cmake_policy(SET CMP0054 NEW)
... module code ...
cmake_policy(POP)
Until such time as someone wishes to port a module explicitly
with the above approach we can use the
Again, shouldn't we consider having CMP0011 always NEW for internal modules /
or do implicit pushpop for include when CMP0011 is NEW *OR* when included
module is part of CMake own modules?
--Adam
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 09/24/2014 10:49 AM, Adam Strzelecki wrote:
do implicit pushpop for include when CMP0011 is NEW *OR*
when included module is part of CMake own modules
I think this would be okay, as long as NO_POLICY_SCOPE
is still honored when given explicitly to include() and
find_package(). The only
On 09/21/2014 02:48 PM, Adam Strzelecki wrote:
FYI unfortunately this solution does not work for CMakeFiles.txt
with cmake_minimum_required(VERSION 2.6.1) or earlier because of
CMP0011 that does implicit PUSH/POP does not work there. So
setting cmake_policy(SET CMP0054 NEW) is internal modules
FYI unfortunately this solution does not work for CMakeFiles.txt with
cmake_minimum_required(VERSION 2.6.1) or earlier because of CMP0011 that does
implicit PUSH/POP does not work there. So setting cmake_policy(SET CMP0054 NEW)
is internal modules will cause this policy to be not popped and
Addendum: Maybe CMP0011 should be forced implicitly for all built-in modules?
--Adam
--
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
I've pushed stage/CMP0054-FindCUDA:
commit 8998557e7c9a7542e78e07b8b06fd728604f0bdf
Author: Adam Strzelecki o...@java.pl
Date: Tue Sep 16 23:31:44 2014 +0200
FindCUDA: Audit for modern CMP0054 if() syntax
Enables CMP0054 for whole module to silence quoted variable expansion
On 09/19/2014 07:30 AM, James Bigler wrote:
Could someone please explain to me why we need to change all the if
statements to look super ugly?
It sounds like you might have missed the follow up within this thread.
Expanding WIN32 to dereference the value is just a recipe for
confusion.
Since the policy may or may not be active (depending on the user's project)
they might be using FindCUDA.cmake with CMP0054 set to NEW or OLD. To get
identical (and warning free) behavior irregardless of the current policy
setting Adam added the proposed ugliness.
Putting my 2ยข, we can
I like the cmake_policy(SET CMP0053 NEW) solution, too. We should
make a concerted effort to encourage module maintainers to do this
before the 3.1 release for as many modules as possible.
D
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
Could someone please explain to me why we need to change all the if
statements to look super ugly?
Expanding WIN32 to dereference the value is just a recipe for confusion.
Honestly I would prefer if there was a policy to never deference variables
in if statements and replace the if's with:
if
This silents possible CMP0054 related warnings.
---
Modules/FindCUDA.cmake | 14 +++---
Modules/FindCUDA/run_nvcc.cmake | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 9348aa5..2e2b21c 100644
---
Wait, what? This is actually the opposite of what that policy is for, no?
Adam, I don't blame you, just to get that said first. The question is: does
this policy warning trigger far too often?
Yes, you are absolutely right. But the problem is that internal modules run in
whatever policy is
On 17.09.2014 14:48, Nils Gladitz wrote:
Maybe modules loaded from the cmake installation itself should
implicitly have their policy version set to the current cmake version?
I pushed root-modules-set-policies-new to stage which sets all
policies to NEW for modules from cmake's own
14 matches
Mail list logo
