[cmake-developers] LINK_LIBRARIES property topic

Stephen Kelly steveire at gmail.com
Mon Jan 7 15:26:53 EST 2013


Brad King wrote:

> Steve,
> 
> I've reviewed this topic:
> 
>  4cf80cc Make sure types match exacty without conversion when making
>  std::pairs. 786aa36 Fix (hopefully) the Mac build.
>  9bb1f54 Populate the LINK_LIBRARIES property when linking to targets.
>  1381d56 Add a HEAD-target to target linking API.
> 
> I'm hesitant to use
> 
>  std::pair<cmTarget*, std::string>
> 
> as a map key.  I had to read the commit history of it to understand
> what it represents.  Please use a helper struct with a suitable name
> instead.  Then squash the fixup commits back into the main HEAD-target
> commit.

Done.

> 
> Also, I see a few uses of GetOriginalLinkLibraries left.  The only one
> we should have left is the one for the CMP0003 OLD behavior.

The other uses are in cmGlobalGenerator and in the Graphiviz generator.

In cmGlobalGenerator it is used at configure-time, so we can't evaluate 
generator expressions, and shouldn't read LINK_LIBRARIES property directly 
because it can contain generator expressions set via set_property. 

Additionally, in a future patch, I strip out generator expressions before 
adding them to the OriginalLinkLibraries, so I think leaving that call there 
makes sense to get the link libraries known at configure time:

 https://gitorious.org/~steveire/cmake/steveires-
cmake/commit/e18ddcd0fcfccdefcd8d6a5303fc809985cf9746

If you insist, I can rename the method, but I think that would be just noise 
in the history.

The uses in the Graphviz generator are also called at configure-time. 
Downstreams may be relying on that and using the generated graphs in 
add_custom_target or similar. 

Additionally, the graphiviz generator does not generate multiple config-
specific graph files (I think there is a bug for that, but I don't know 
where), nor does it put config specific information in all one graph (which 
should it do - it's an open question), so we can't use the information in 
generator expressions.

I think it's a can of worms to try to do all that now, and it's a world away 
from the branch we're really trying to get integrated, and it will require 
discussion and maybe a policy etc.

Thanks,

Steve.





More information about the cmake-developers mailing list