On Fri, Dec 25, 2015 at 4:35 AM, David Faure <fa...@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 <fa...@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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem