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
