Brad King wrote: > On 4/29/2012 11:02 AM, Stephen Kelly wrote: >> The topic of 'target usage requirements' has come up several times. It's >> something I'd like to work further towards in CMake 2.8.9. >> >> I have created a wiki page on the KDE wiki (there for my convenience >> mostly) so that we can discuss the design, implementation and >> implications. >> >> http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements > > Great start. Thanks for working on this. Here are some comments. > (BTW, I think the dir-level and target-level column labels are > backwards in the summary table.)
Fixed, thanks. > > The definition of a package for the RHS of target_use_package needs > some refinement. What if find_package(Bar) brings in an imported > target called Bar that also defines usage requirements? How does > a later target_use_package(... Bar) know what to use? It would use a well defined order. Maybe first assuming it's a package, then assuming it's an imported target, then assuming it's a prefix. But actually, I think Alex' suggestion solves the problem anyway: target_use_package(Foo IMPORTED_TARGETS Bar) target_use_package(Foo VIA_PREFIX Bar ) target_use_package(Foo PACKAGE Bar) > We will likely need to make packages something first-class on the > C++ side. If find_package(Bar) detects that the files it loaded > define sufficient information for a package it should construct a > C++ object to represent the package. This event should establish > the package. A loose sequence of variable set()s is not explicit > enough. Right. > > Either way we need to establish when a main or imported target is > a package versus when it is part of another package. > > We need to settle on a generator-expression syntax for per-config > conditions. The $<CONFIG?Debug:...> syntax is sufficient for > discussion but needs more thorough discussion before it is final. > Can you post a link to wherever it was you first saw me mention it? http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2145/focus=2359 In particular, I think it might be necessary to set multiple conditions in such expressions. In the example below I don't use the same semantic as above, but something simliar to url query strings: set_target_property(Foo INTERFACE_INCLUDE_DIRS "$<INCLUDE_MODE=Build:${CMAKE_SOURCE_DIR}/src/foo/debugstuff>" "$<CONFIG=Debug?INCLUDE_MODE=Build:${CMAKE_SOURCE_DIR}/src/foo>" "$<INCLUDE_MODE=Install:${CMAKE_INSTALL_PREFIX}/mylib>" ) > One goal you mention is to avoid parameterizing property names > over configurations, languages, etc. Perhaps generator expressions > can handle that inside the value, as in "$<LANGUAGE?C:...>". This > will require a more general version of "$<CONFIG?...>" too. I'd > like to be careful to keep things simple and not create a whole new > generation-time evaluation language. Yes, I think we'll need to first have a list of 'dimensions' that are relevant. I wasn't sure language is a relevant one, because I thought that a target would only be compiled with one language. Thinking about it more, a C library can be used from CXX code, and may require other DEFINES in that case, so I guess it is a relevant dimension. Is there anything missing from the list I made? 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
