[cmake-developers] [PATCH 1/2] cmComputeLinkInformation: Don't add build dependencies on IMPORTED libraries

Brad King brad.king at kitware.com
Fri Jun 6 11:18:15 EDT 2014


On 06/06/2014 11:09 AM, Sam Spilsbury wrote:
> The only potential side effect is that there will be no re-linking
> where an imported library changes on disk outside the project. I can
> see how this is potentially a bad thing, though I am not sure if it
> was a design goal of imported libraries.

It would be a bad thing to drop such dependencies and they are an
explicit design goal for imported libraries.

> It isn't clear to me how this can be fixed locally.
> cmNinjaTargetGenerator::ComputeLinkDeps() gets a list of dependencies
> from cmComputeLinkInformation directly. We can't query whether or not
> a dependency was an imported target and should be disregarded because
> it has already been converted to a string at that point.

If a path comes out of cmComputeLinkInformation then the generator
must provide a dependency on it.  It is not up to the generator to
decide whether a particular dependency is worthwhile or not.  The
VS, Xcode, and Makefile generators all work correctly.  The Ninja
generator must find a way to do it.

It is undefined behavior for an IMPORTED_LOCATION to be a relative
path, so all dependencies coming out of cmComputeLinkInformation
should be full paths.

-Brad




More information about the cmake-developers mailing list