[cmake-developers] Generator expressisons in target properties (was Re: conditionals in generator expressions)

[Brad King]

On 10/23/2012 09:13 AM, Stephen Kelly wrote:
> What is 'link-aware code'? A part of the cmake implementation that has rules 
> specific to linking where the difference between the direct and transitive 
> dependencies is important?

cmComputeLinkDepends is exclusively responsible for handling transitive
link dependencies.  It has non-trivial logic that took years to get right.
Don't try to replace it with a simple genex-based transitive closure.

> However, if the direct and transitive dependencies really must be kept 
> separate, that will have to be rethought anyway.

They do.  A few years ago I went through major pain to drop uses of the
old GetLinkLibraries and use either GetOriginalLinkLibraries or results
from cmComputeLinkDepends wherever possible.  It is necessary to keep
them separate because cmComputeLinkDepends needs to know exactly what
the user originally specified as direct dependencies in order to compute
the closure properly.

> For example, it makes sense for POSITION_INDEPENDENT_CODE, so Qt5Core should 
> have INTERFACE_POSITION_INDEPENDENT_CODE ON and the 
> POSITION_INDEPENDENT_CODE property should be evaluated with EACH as I 
> pseudo-implemented in my patch. 

Just like link dependencies I fear the transitive behavior of each build
property may need custom C++ code.

> I can't think of a reason to link a library based on whether 
> POSITION_INDEPENDENT_CODE is true or false for a target.

A package could provide a PIC and non-PIC version of a library and
pick one based on whether the target is PIC or not.

> In somewhat more concrete terms, maybe if the STD_CXX11 property ever 
> becomes a reality, a library built with c++11 might require that downstreams 
> also use c++11 because of binary compatibility concerns in the stdlib 

IMO that should be a detect-and-reject case rather than propagated:

 CMake Error ...:
  Target foo has STD_CXX11=OFF but links bar with STD_CXX11=ON.

Just like PIC and WIN32 a package can provide multiple libraries and
select them conditionally on the needs of the final target.

I think the general philosophy is that the final target should specify
how it wants to build and the libraries it links evaluate their exprs
to meet its requirements.  If they can't then it is an error.

>> We may need a policy implemented with minimum duplication to provide
>> the capabilities that export() used to.
> 
> Would the policy be used to determine whether to execute the export() at 
> configure-time (and strip out any generator expressions found) or at 
> generate-time (and process the generator expressions)?

Something like this, yes.  It may be really nasty to know when to
trigger the policy because we need to know whether the project loads
its own export() output.  It may be simpler to define the export()
behavior with an explicit option or with CMAKE_MINIMUM_REQUIRED_VERSION.

> It still looks like a lot of duplication to me (my commit that moves 
> HasSOName and all previous commits may need to be copied). Maybe it's not as 
> bad as it seems though.

Policies were first introduced because of the need for CMP0003 after
some major internal changes to the way link lines are computed.  I
actually first had the new link implementation done without any policy.
If all projects were written according to our documented behavior then
there would have been no need for more work.  However, every single
major client project at the time (including KDE, ITK, VTK, and ParaView)
had cases where things had only been working accidentally due to details
of the prior implementation.  It took over TWO PERSON MONTHS more work
to introduce policies and CMP0003 to make things compatible.

This stuff isn't easy.  You're talking about fundamental changes to
the way CMake processes the most basic and common interfaces used by
projects (include dirs, link libs, etc.).

-Brad