Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
Brad King wrote: On 01/28/2013 12:27 PM, Stephen Kelly wrote: Yes. However code like this would be ambiguous until generate-time: target_include_directories(foo PRIVATE bar) Is bar a target or a directory? That means storing a longer string for bar: Simply saying that an existing directory with the given name has priority over a target with the same name would not be ok ? Currently we do the opposite. First check if 'bar' is a target name, and if not, then treat it as a directory. Can we consider using syntax to make this unambiguous? For non-targets we can require at least one slash to subsume full paths and allow relative paths: target_include_directories(foo PRIVATE bar/ ./zot) That wouldn't work. I needed this patch: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aca4916b2c124c6ec198c1f88329379458c93727 for this error: http://open.cdash.org/testDetails.php?test=173056412build=2758124 Perhaps the existence of a non-slash subdirectory could also be enough for a non-target. There is the disadvantage that the case of target_compile_definitions(foo PRIVATE SOME_DEFINE) now expands in the COMPILE_DEFINITIONS property to $$TARGET_DEFINED:SOME_DEFINE: $TARGET_PROPERTY:SOME_DEFINE,INTERFACE_COMPILE_DEFINITIONS;$$NOT: $TARGET_DEFINED:SOME_DEFINE:SOME_DEFINE If SOME_DEFINE is *already* a target then this is not needed. Only out-of-order cases need it. Yes, but that is the common case. Also we should be able to perform partial evaluation at generate time so that the exported interface does not have this. Users could also write target_compile_definitions(foo PRIVATE bar=) to state that 'bar' is a definition name and not a target. Yes. We could also allow/accept a -D in front of definition names and have tcd() strip them out when setting the property. I don't like that idea. It already makes add_definitions complex. This would also help in cases where variables contain lists meant for the old add_definitions command which wants -D. True, but I think moving away from having a compiler-specific syntax to add definitions is a good thing. What's missing is a concise syntax to say that a string *is* a target. One could write $TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS but that exposes the plumbing. Ideas? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
Brad King wrote: On 01/28/2013 02:30 PM, Brad King wrote: Can we consider using syntax to make this unambiguous? What's missing is a concise syntax to say that a string *is* a target. One could write $TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS but that exposes the plumbing. Ideas? Actually solving this would solve the ambiguity problem by allowing us to require special syntax for referencing targets from tid and tcd. This may also address Alex's concern over in http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5904/focus=5945 On 01/28/2013 01:05 PM, Alexander Neundorf wrote: Is it maybe a bit inconsistent that - to setup linking, I can use tll() with targets and with paths - to setup include dirs, I can use tll() with targets, or tid() with targets and directories, or id() with directories Should include_directories() maybe also be taught to recognize targets ? I mean, it kind of makes sense that tll() does not (will not) handle directories for setting up include dirs, but I'm still not sure I like that tll() will handle linking completely and partly setting up the includes. I'm not sure what you mean by 'partly'. What if only tll continues to allow raw target names and tid and tcd assume non-target without using a generator expression? In the common use case tll will now do linking/includes/defines for targets anyway so we will need tid and tcd only for real raw dirs/defs. Yes, I think that's right. As a somewhat real-world use of this stuff, see this patch to the kde- frameworks branch: http://www.steveire.com/0001-wip-remove-redundant-include_directories- calls.patch (There's some X11 and other dependency stuff mixed in, so ignore those parts) So, the conclusion is that we can remove target handling from target_compile_definitions and target_include_directories entirely? Should we wait for the conclusion of the upstream/downstream/policy issue in the other thread? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On 01/29/2013 04:07 AM, Stephen Kelly wrote: target_include_directories(foo PRIVATE bar/ ./zot) That wouldn't work. I needed this patch: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aca4916b2c124c6ec198c1f88329379458c93727 for this error: http://open.cdash.org/testDetails.php?test=173056412build=2758124 It would work if you took the trailing slash to mean directory but then stripped it off. I think the point is moot given the other side of this thread is about to conclude that we shouldn't support target names at all. This would also help in cases where variables contain lists meant for the old add_definitions command which wants -D. True, but I think moving away from having a compiler-specific syntax to add definitions is a good thing. It's not really compiler-specific, it's just the interface of add_definitions. The command parses out the -D as syntax and then passes the definition to the same plumbing as COMPILE_DEFINITIONS. I think this feature could be added to tcd() to help projects transition use of existing Foo_DEFINITIONS variables meant for add_definitions. It certainly doesn't belong in the plumbing though. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On 01/29/2013 04:23 AM, Stephen Kelly wrote: that tll() will handle linking completely and partly setting up the includes. I'm not sure what you mean by 'partly'. I think Alex meant that plain directories cannot be added with tll for includes. However, we have to be careful not to mix up configuration of the target's own build requirements versus propagation of requirements from dependencies. The former should still use tid and tcd while the latter will now be fully handled by tll. What if only tll continues to allow raw target names and tid and tcd assume non-target without using a generator expression? In the common use case tll will now do linking/includes/defines for targets anyway so we will need tid and tcd only for real raw dirs/defs. Yes, I think that's right. As a somewhat real-world use of this stuff, see this patch to the kde- frameworks branch: http://www.steveire.com/0001-wip-remove-redundant-include_directories-calls.patch Nice! So, the conclusion is that we can remove target handling from target_compile_definitions and target_include_directories entirely? Yes, especially if it works for your real-world case. Whenever one really wants to use a target one can use the plumbing directly: $TARGET_PROPERTY:mydep,INTERFACE_INCLUDE_DIRECTORIES Should we wait for the conclusion of the upstream/downstream/policy issue in the other thread? Aren't these issues orthogonal (other than merge conflicts)? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
Brad King wrote: On 01/29/2013 04:23 AM, Stephen Kelly wrote: that tll() will handle linking completely and partly setting up the includes. I'm not sure what you mean by 'partly'. I think Alex meant that plain directories cannot be added with tll for includes. However, we have to be careful not to mix up configuration of the target's own build requirements versus propagation of requirements from dependencies. The former should still use tid and tcd while the latter will now be fully handled by tll. Yes. What if only tll continues to allow raw target names and tid and tcd assume non-target without using a generator expression? In the common use case tll will now do linking/includes/defines for targets anyway so we will need tid and tcd only for real raw dirs/defs. Yes, I think that's right. As a somewhat real-world use of this stuff, see this patch to the kde- frameworks branch: http://www.steveire.com/0001-wip-remove-redundant-include_directories- calls.patch Nice! So, the conclusion is that we can remove target handling from target_compile_definitions and target_include_directories entirely? Yes, especially if it works for your real-world case. Whenever one really wants to use a target one can use the plumbing directly: $TARGET_PROPERTY:mydep,INTERFACE_INCLUDE_DIRECTORIES Yes that's fine. We could add a TARGETS keyword to the new commands, but as that would be about usage-requirements propagation - which we want to specify using tll instead - I don't think we need to do that. Should we wait for the conclusion of the upstream/downstream/policy issue in the other thread? Aren't these issues orthogonal (other than merge conflicts)? Yes, I don't really know why I wrote that. Maybe only because of the merge conflicts issue. I guess it would be easier to have what is in next merged to master or removed (interface-commands-lazy-target-check) so that we can start with a clean slate and see what's left. fix-relocatable-include-dirs is a potential source of conflict with what we've been discussing. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On 01/29/2013 01:28 PM, Alexander Neundorf wrote: On Tuesday 29 January 2013, Brad King wrote: Yes, especially if it works for your real-world case. Whenever one really wants to use a target one can use the plumbing directly: $TARGET_PROPERTY:mydep,INTERFACE_INCLUDE_DIRECTORIES Ok. Can support for this then also be added to include_directories(), or would this break something ? My understanding is that this should already be the case. The generator expression argument will just be added to the same places a plain directory name would and then be evaluated by the generator later. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On Sunday 27 January 2013, Stephen Kelly wrote: Alexander Neundorf wrote: Is there a reason why target_include_directories() should behave differently ? That results from the semantics of the INCLUDE_DIRECTORIES property and http://public.kitware.com/Bug/view.php?id=13188 Ok. This applies to setting the target property directly. But, I think target_include_directories() could still handle relative paths so that CMAKE_CURRENT_SOURCE_DIR is prepended before it is set as a target property. Yes. However code like this would be ambiguous until generate-time: target_include_directories(foo PRIVATE bar) Is bar a target or a directory? That means storing a longer string for bar: Simply saying that an existing directory with the given name has priority over a target with the same name would not be ok ? This would mean that directories shadow targets (or only not-yet-existing targets), while the other way round targets shadow directories. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5734/focu s=5920 https://gitorious.org/~steveire/cmake/steveires- cmake/commit/6fcdd6e4d47d0469baad228a84ebb9269dceb488 I don't know if that has a big impact but it's an unfortunately long string to have to store for such a small input. We can also allow relative directories in a later release anyway. I'd prefer at this point to be focussed on things which do have to be in this release. Yes. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
Alexander Neundorf wrote:
On Sunday 27 January 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
Is there a reason why
target_include_directories() should behave differently ?
That results from the semantics of the INCLUDE_DIRECTORIES property
and http://public.kitware.com/Bug/view.php?id=13188
Ok.
This applies to setting the target property directly.
But, I think target_include_directories() could still handle relative
paths so that CMAKE_CURRENT_SOURCE_DIR is prepended before it is set as
a target property.
Yes. However code like this would be ambiguous until generate-time:
target_include_directories(foo PRIVATE bar)
Is bar a target or a directory? That means storing a longer string for
bar:
Simply saying that an existing directory with the given name has priority
over a target with the same name would not be ok ?
Currently we do the opposite. First check if 'bar' is a target name, and if
not, then treat it as a directory.
This would mean that directories shadow targets (or only
not-yet-existing targets), while the other way round targets shadow
directories.
As directories should be set up front, that could be a good idea and could
indeed allow us to determine at configure-time if 'bar' is a directory or
might be a target.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5734/focu
s=5920
https://gitorious.org/~steveire/cmake/steveires-
cmake/commit/6fcdd6e4d47d0469baad228a84ebb9269dceb488
I don't know if that has a big impact but it's an unfortunately long
string to have to store for such a small input.
We can also allow relative directories in a later release anyway. I'd
prefer at this point to be focussed on things which do have to be in this
release.
Yes.
Although if we're going to change from
if (target) {} else if (directory) {}
to
if (directory) {} else if (target) {}
we should do that this release.
I can have a look later/tomorrow depending on whether anything gets merged
today. It would require refactoring which would conflict with my interface-
commands-lazy-target-check branch.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On 01/28/2013 12:27 PM, Stephen Kelly wrote: Yes. However code like this would be ambiguous until generate-time: target_include_directories(foo PRIVATE bar) Is bar a target or a directory? That means storing a longer string for bar: Simply saying that an existing directory with the given name has priority over a target with the same name would not be ok ? Currently we do the opposite. First check if 'bar' is a target name, and if not, then treat it as a directory. Can we consider using syntax to make this unambiguous? For non-targets we can require at least one slash to subsume full paths and allow relative paths: target_include_directories(foo PRIVATE bar/ ./zot) Perhaps the existence of a non-slash subdirectory could also be enough for a non-target. There is the disadvantage that the case of target_compile_definitions(foo PRIVATE SOME_DEFINE) now expands in the COMPILE_DEFINITIONS property to $$TARGET_DEFINED:SOME_DEFINE:$TARGET_PROPERTY:SOME_DEFINE,INTERFACE_COMPILE_DEFINITIONS;$$NOT:$TARGET_DEFINED:SOME_DEFINE:SOME_DEFINE If SOME_DEFINE is *already* a target then this is not needed. Only out-of-order cases need it. Also we should be able to perform partial evaluation at generate time so that the exported interface does not have this. Users could also write target_compile_definitions(foo PRIVATE bar=) to state that 'bar' is a definition name and not a target. We could also allow/accept a -D in front of definition names and have tcd() strip them out when setting the property. This would also help in cases where variables contain lists meant for the old add_definitions command which wants -D. What's missing is a concise syntax to say that a string *is* a target. One could write $TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS but that exposes the plumbing. Ideas? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On 01/28/2013 02:30 PM, Brad King wrote: Can we consider using syntax to make this unambiguous? What's missing is a concise syntax to say that a string *is* a target. One could write $TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS but that exposes the plumbing. Ideas? Actually solving this would solve the ambiguity problem by allowing us to require special syntax for referencing targets from tid and tcd. This may also address Alex's concern over in http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5904/focus=5945 On 01/28/2013 01:05 PM, Alexander Neundorf wrote: Is it maybe a bit inconsistent that - to setup linking, I can use tll() with targets and with paths - to setup include dirs, I can use tll() with targets, or tid() with targets and directories, or id() with directories Should include_directories() maybe also be taught to recognize targets ? I mean, it kind of makes sense that tll() does not (will not) handle directories for setting up include dirs, but I'm still not sure I like that tll() will handle linking completely and partly setting up the includes. What if only tll continues to allow raw target names and tid and tcd assume non-target without using a generator expression? In the common use case tll will now do linking/includes/defines for targets anyway so we will need tid and tcd only for real raw dirs/defs. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
Alexander Neundorf wrote: Hi, the docs for the new target_include_directories() say that it accepts only absolute paths. Why is that so ? include_directories() (and also link_directories(), see CMP0015) both accept relative paths and interpret them as relative to CMAKE_CURRENT_SOURCE_DIR. Is there a reason why target_include_directories() should behave differently ? That results from the semantics of the INCLUDE_DIRECTORIES property and http://public.kitware.com/Bug/view.php?id=13188 Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On Sunday 27 January 2013, Stephen Kelly wrote: Alexander Neundorf wrote: Hi, the docs for the new target_include_directories() say that it accepts only absolute paths. Why is that so ? include_directories() (and also link_directories(), see CMP0015) both accept relative paths and interpret them as relative to CMAKE_CURRENT_SOURCE_DIR. Is there a reason why target_include_directories() should behave differently ? That results from the semantics of the INCLUDE_DIRECTORIES property and http://public.kitware.com/Bug/view.php?id=13188 Ok. This applies to setting the target property directly. But, I think target_include_directories() could still handle relative paths so that CMAKE_CURRENT_SOURCE_DIR is prepended before it is set as a target property. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
Alexander Neundorf wrote: Is there a reason why target_include_directories() should behave differently ? That results from the semantics of the INCLUDE_DIRECTORIES property and http://public.kitware.com/Bug/view.php?id=13188 Ok. This applies to setting the target property directly. But, I think target_include_directories() could still handle relative paths so that CMAKE_CURRENT_SOURCE_DIR is prepended before it is set as a target property. Yes. However code like this would be ambiguous until generate-time: target_include_directories(foo PRIVATE bar) Is bar a target or a directory? That means storing a longer string for bar: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5734/focus=5920 https://gitorious.org/~steveire/cmake/steveires- cmake/commit/6fcdd6e4d47d0469baad228a84ebb9269dceb488 I don't know if that has a big impact but it's an unfortunately long string to have to store for such a small input. We can also allow relative directories in a later release anyway. I'd prefer at this point to be focussed on things which do have to be in this release. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
