Re: [CMake] target_include_directories and relative paths inside generator expressions.
Andrew Fuller wrote: > It seems absolute paths are necessary. eg: > > target_include_directories( MyTarget PRIVATE > $<$:${CMAKE_CURRENT_SOURCE_DIR}/some/dir> ) > > will perform as expected. > > Is this behaviour expected (and should be documented) or should I file a > bug? CMake doesn't know at configure-time what the $<...> at the start of the path will evaluate to at generate time (It could even be different things, depending on the config). I thought that would be obvious, but a patch to Help/manual/cmake-buildsystem.7.rst or Help/command/target_include_directories.rst might help. Thanks, Steve. -- 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
Re: [CMake] Explanation....
On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote: > > if (" ${arg}" STREQUAL " TOTO") > > set(" TOTO" "evil") You sure? When I checked, this did not work. Also, the following gives me a syntax error: set (" foo" "Evil!") message( "${ foo}") Syntax error in cmake code at /home/zing/scratch/cmake_testbed/CMakeLists.txt:100 when parsing string ${ foo} syntax error, unexpected cal_SYMBOL, expecting } (7) > See also > http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936. This is totally different, in that it uses an unsafe prefix. Just like the "_ASDF_" I used in my first response, the "x" *can* be the beginning of a variable name. The space can not start a vaariable name. Cheers, Johannes -- 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
Re: [CMake] Explanation....
> 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
Re: [CMake] Explanation....
On 2014-04-24 04:53, Johannes Zarl wrote: On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote: if (" ${arg}" STREQUAL " TOTO") set(" TOTO" "evil") You sure? When I checked, this did not work. Are *you* sure? :-) Also, the following gives me a syntax error: message( "${ foo}") Right; *explicit* expansion is limited in what characters are allowed. As David Cole points out, you must expand such variables indirectly. Of course, implicit expansion counts as indirect expansion, which is why there is no safe character/prefix that can guarantee implicit expansion won't occur. (And - again as David Cole already noted - you didn't get an error in the set() command, did you?) See also http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936. This is totally different, in that it uses an unsafe prefix. No it doesn't. The point being made there (and here) is that *ANY* prefix is unsafe. (Granted, some are more unsafe than others...) On 2014-04-24 06:31, David Cole wrote: I, for one, would fully support breaking backwards compatibility to fix this, and be strict with variable and macro and function name identifiers. Of course, the *real* problem is implicit expansion. The permissiveness of variable naming makes it harder to work around this, but would be less of an issue if implicit expansion was less "eager". -- Matthew -- 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
Re: [CMake] target_include_directories and relative paths inside generator expressions.
On Thu, Apr 24, 2014 at 1:21 AM, Stephen Kelly wrote: > Andrew Fuller wrote: > > > It seems absolute paths are necessary. eg: > > > > target_include_directories( MyTarget PRIVATE > > $<$:${CMAKE_CURRENT_SOURCE_DIR}/some/dir> ) > > > > will perform as expected. > > > > Is this behaviour expected (and should be documented) or should I file a > > bug? > > CMake doesn't know at configure-time what the $<...> at the start of the > path will evaluate to at generate time (It could even be different things, > depending on the config). Oh okay. I didn't realize that expanding relative paths to absolute would be done prior to evaluating the generator expression. Now that I know that detail the current behaviour is understandable. Thanks for the clarification. -- 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