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
