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
