> You sure? When I checked, this did not work. Also, the following
> gives me a syntax error:
>
> set (" foo" "Evil!")
> message( "${ foo}")
But you *can* still do it indirectly (even with the 3.0 RCs):
set (" variable with spaces" "Evil too!")
set (varname " variable with spaces")
message("${${varname}}")
(Sorry, but I refuse to use "foo" in example code...)
You'll notice that in your original example, the error was reported on
the "message" command. The parser simply could not parse a directly
coded variable name containing spaces inside the context of ${}... but
de-referencing indirectly, as is commonly done, still makes it possible
to end up with weirdly named variables if you're not extremely careful
with your variable naming schemes.
I, for one, would fully support breaking backwards compatibility to fix
this, and be strict with variable and macro and function name
identifiers.
It's just ridiculous to waste time trying to justify the existing
behavior. It's more confusing than useful, and ought to be changed.
Just my opinion,
David C.
--
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://www.cmake.org/mailman/listinfo/cmake
