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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
