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

[Stephen Kelly]

Brad King wrote:

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

No problem. That stuff is in the wip topic for a reason :). 

I was really just doing what had to be done in order to make it possible to 
see the expression I needed in to get conditional linking to Qt5::WinMain 
working to proove the concept.

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

Yes, something like that could work.

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

Right, that's the kind of design choice that we might be able to make to 
clear away the cycles problem. It's something we'll have to enforce from the 
start somehow though. Hopefully the use of generator expressions in 
INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS in 2.8.10 doesn't get in the way 
of what we need to do to enforce something like that in 2.8.11.
 
>>> 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.  

One way would be for include() and find_package() to query the global 
generator to find if a makefile has a cmExportBuildGenerator which outputs 
the argument (add a GetMainImportFile). Apart from those two commands, are 
there other ways of using an export()ed file as input at configure-time?

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

Yes, I understand that, and I'm grateful for the design and implementation 
dialog. 

Don't get me wrong - I don't suggest to introduce 'intentional breakage' in 
the release that all downstreams have to work around. Downstream code using 
export() like that is something I hadn't known was possible. I agree that we 
need a solution where existing code continues to work.

Thanks,

Steve.