[cmake-developers] cost of usage requirements

[Brad King]

On 06/11/2014 10:46 AM, Brad King wrote:
> However, please look at improving the implementation to have
> something under O(n^2) complexity when the usage requirements
> do not actually depend on the headTarget.

After looking through the related code I have a few other comments.

I see a lot of duplication of evaluating the link impl.  Loops
over LinkImplementationPropertyEntries appear for each usage
requirement type.  I think that can be converted to use a method
like GetLinkImplementationLibraries if we were to add backtrace
information to the cmTarget::LinkImplementation list of libraries.

Can the dagChecker used for INTERFACE_SOURCES be moved into
GetDirectLinkLibraries or ComputeLinkImplementation?  Then the
loop over LinkImplementationPropertyEntries for SOURCES could
be converted too.

Why do GetLinkImplementationLibraries and GetLinkImplementation
need a headTarget argument?  The LINK_LIBRARIES are private to
the implementation of a target itself.  Only the link interface
should be considered when headTarget != this.

I noticed some headTarget->GetMakefile()->FindTargetToUse()
calls.  This is not a safe way to look up a target name
referenced by the currentTarget because imported target
names are scoped by directory.  See the attached example
for some failure cases.  Read B/CMakeLists.txt comments.
I think those are triggered by the call in processILibs.
I'm having trouble producing example breakage for the
calls in GetTransitivePropertyTargets, but they look
incorrect too.  FindTargetToUse always needs to be called
on the cmMakefile context of the target whose link info
references the name to be found.

Thanks,
-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad-imported-target-lookup.tar.gz
Type: application/gzip
Size: 793 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20140611/298d0cbe/attachment-0002.bin>