[cmake-developers] Target usage requirements and conventions

[Stephen Kelly]

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.