On 09/04/2014 10:25 AM, Nils Gladitz wrote: > This keeps coming up and there probably have been many discussions on > how this might be "fixed" as well.
As I have explained every other time it has come up there is exactly one way to fix it: a policy that makes expansion happen only for unquoted arguments. Someone just has to do it. > I am wondering if we could provide an alias for the "if" command (e.g. > "safe_if") that would inherit cmIfCommand but would reimplement > GetVariableOrString() without the variable lookup. > > This would leave if() behavior intact for compatibility but would > provide an alternative with less surprising semantics. I think a new command would ("if_noexpand") would make the "correct" code less readable than the "incorrect" code. Also the implicit-bool conversion of variables is more readable IMO; consider if(${FOO_FOUND}) versus if(FOO_FOUND) On 09/04/2014 10:32 AM, David Cole via cmake-developers wrote: > Another approach might be to add STRING_EQUAL and STRING_MATCHES (or > similarly unambiguous names) operators that do not do the variable > lookup. This is a reasonable proposal but the difference to STREQUAL and MATCHES is quite subtle. Also adding more operators this late in the game is more likely to collide with variable names people already use. -Brad -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers