Alexander Neundorf wrote: > On Sunday 13 May 2012, Stephen Kelly wrote: >> Stephen Kelly wrote: >> > Hi there, >> > >> > 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 >> > >> > Thanks for any comments, >> >> Hi there, >> >> Thanks for the feedback on this proposal so far. >> >> I have updated the wiki page to remove any reference to >> target_use_package() or functionality depending on conventions of >> variable names, or finding packages etc. The proposal as written now >> expects the caller to supply targets, and never expects a package name or >> a prefix. >> >> The page is now focussed on creation of a target_use_targets() command >> which operates on targets which are in scope because either they were >> created in the same buildsystem, or they were imported. >> >> It would be possible to revisit the target_use_package() idea in the >> future, but that is no longer the aim of the proposal. The >> target_use_targets() is already a useful enough concept to aim for. > > Great :-) > >> The remaining (I think) open question regards what form the generator >> expressions should take so that they can represent multiple dimensions. > > Some comments: > > will target_use_target() also need PRIVATE and PUBLIC keywords as > target_link_libraries() has now ?
Yes. It may even have to be more granular than that. For example it might be necessary to have include_directories public in a dependency without having public linking (eg if a header is #included which contains defines used in "my" headers). I'm sure that's rare though, so I think we simply need to choose whether to be fully granular, fully monolithic, or somewhere in between. Currently I'm leaning towards fully monolithic. If a target depends publically on another target in any way, that is PUBLIC. > > In installed config/targets files, the include directories must be > relocatable. Added to the wiki. I think that might be tricky to get right. > > Cross compiling: currently the assumption is that > find_library()/find_path() will find files for the target, so inside the > build by default everything is for the target. I don't think this needs > extra handling here. Sounds good. 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
