CMP0064 broken?
Matt McCormick
matt.mccormick at kitware.com
Sat Dec 26 17:27:26 UTC 2015
On Fri, Dec 25, 2015 at 4:35 AM, David Faure <faure at kde.org> wrote:
> On Wednesday 23 December 2015 12:40:33 Matt McCormick wrote:
>> Hi David,
>>
>> On Wed, Dec 23, 2015 at 2:17 AM, David Faure <faure at kde.org> wrote:
>> >> Please try
>> >>
>> >> if ("x${second_PARAM}x" STREQUAL "xTESTx")
>> >
>> > This looks like it should work, but isn't that an awful workaround?
>> > Are we back to shell/autoconf programming from 1990?
>>
>> It is preferable to actually set the policy.
>
> Isn't setting the policy to OLD always considered a bad idea in the long run,
> because that means "yes I know I'm using deprecated behaviour which
> could go away one day"?
> Usually there is a proper way to port to the new behaviour, otherwise
> it means the new behaviour is wrong.
The policy should be set to NEW. Neither the warning message "Use the
cmake_policy command to set the policy and suppress this warning." or
the statement "It is preferable to actually set the policy." means to
set the policy to OLD. Setting the policy to OLD is valid option, but
it is not preferable.
> That's what I'm asking here, what will be the proper way to test that a
> variable contains the string TEST, in 10 years time when CMP0064
> no longer exists?
When
if ("x${second_PARAM}x" STREQUAL "xTESTx")
is entered, a CMP0064 warning is emitted after a CMP0054 warning is
emitted. The documentation of CMP0054 says:
https://cmake.org/cmake/help/v3.4/policy/CMP0054.html
"Only interpret if() arguments as variables or keywords when unquoted."
So, set CMP0054 to NEW.
The documentation for cmake_policy is here:
https://cmake.org/cmake/help/v3.4/command/cmake_policy.html
If other projects using this code should not have the policy set, then
PUSH and POP the policy. If versions of CMake need to be supported
before the policy was introduced, then use if(POLICY.
Here is example code:
if(POLICY CMP0054)
cmake_policy(PUSH)
cmake_policy(SET CMP0054 NEW)
if ("${second_PARAM}" STREQUAL "TEST")
# ...
endif()
cmake_policy(POP)
endif()
>> PS. Please send these questions on the appropriate mailing list (cmake-users).
>
> I can't exactly subscribe to 50 mailing-lists, days are too short to follow every
> opensource project in the world.
>
> I thought you might want to know about breakages introduced by your change.
> Clearly my feedback isn't welcome, I'm being told to live with it and use awful
> workarounds, or to fix it myself. That's not a very satisfactory outcome.
Mailing lists ensure that many people in a community can scalably
answer questions and that answers are archived to help community
members do research before asking questions.
At a minimum, take the time to subscribe to a mailing list before
asking a question.
Well researched questions, sent to the appropriate mailing list,
respectfully, with a genuine desire to help are welcome.
I will not spend further time replying in this thread or similar ones.
Matt
More information about the Kde-buildsystem
mailing list