[cmake-developers] Target usage requirements and conventions

[Stephen Kelly]

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.