[cmake-developers] Target usage requirements and conventions

Brad King brad.king at kitware.com
Mon Apr 30 15:07:15 EDT 2012


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.)

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?

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.

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?

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.

-Brad



More information about the cmake-developers mailing list