On 09/24/2014 10:49 AM, Adam Strzelecki wrote:
> do implicit push&pop 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 re
Again, shouldn't we consider having CMP0011 always NEW for internal modules /
or do implicit push&pop 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:
http://
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
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 modu
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
informati
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 carr
I've pushed stage/CMP0054-FindCUDA:
commit 8998557e7c9a7542e78e07b8b06fd728604f0bdf
Author: Adam Strzelecki
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
warning.
Just add
I agree with David, I think moving packages over to using CMP0054 NEW
is the best option going forward.
Personally I think that CMP0054 might be the best policy ever, as it
significantly reduces the complexity of reading CMake code.
On Fri, Sep 19, 2014 at 6:23 AM, David Cole via cmake-developers
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:
http://www
> 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
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. Hon
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
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 Modul
> Maybe modules loaded from the cmake installation itself should implicitly
> have their policy version set to the current cmake version?
Yes, this is what I was going to suggest too. All cmake files inside CMake's
own Modules should have implicit latest policy. Although I'd recommend to have
s
> 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 i
On 09/17/2014 02:37 PM, Rolf Eike Beer wrote:
What one actually wants is to write
if(arg STREQUAL "OPTIONS")
i.e. arg will get expanded, "OPTIONS" not. Changing everything away from
that pattern will in fact make things worse, and will not help you if I
introduce an xOPTION variable now. So,
Am 17.09.2014 13:54, schrieb Adam Strzelecki:
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
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
--- a/Modul
18 matches
Mail list logo
