On Fri, Jun 6, 2014 at 10:55 PM, Brad King <brad.k...@kitware.com> wrote:
> On 06/06/2014 10:11 AM, Sam Spilsbury wrote:
>> The solution is just not to add dependencies on such libraries, as any
>> dependencies of the IMPORTED target itself will be added as
>> dependencies of targets depending on the IMPORTED target.
>
> There are no build rules for imported targets so they have no
> dependencies anyway. The patch in question:
>
> // Pass the full path to the target file.
> std::string lib = tgt->GetFullPath(config, implib, true);
> - if(!this->LinkDependsNoShared ||
> - tgt->GetType() != cmTarget::SHARED_LIBRARY)
> + if((!this->LinkDependsNoShared ||
> + tgt->GetType() != cmTarget::SHARED_LIBRARY) && !tgt->IsImported())
> {
> this->Depends.push_back(lib);
> }
>
> touches code used to generate dependencies on a link rule.
> If link rules do not depend on imported libraries then they
> will not re-link when those libraries change on disk. This
> is incorrect.
I'm confused as to what you mean by this. All this change does is
causes a dependency on an imported library not to be added. It doesn't
change the situation when imported libraries are not in use, as those
libraries will be added as dependencies.
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.
>
>> Fixes #13574.
>
> All generators except Ninja are able to deal with this correctly.
> The place to fix it must be in the Ninja generator.
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.
Something that did occur to me while I was testing this was that
adding an IMPORTED library to something inside of an external project
inside the same subdirectory as the target seeking to depend on the
IMPORTED library didn't cause any problems for the generator, but
placing it in a sibling subdirectory with the IMPORTED library being
marked GLOBAL did cause the bug in question. Perhaps its a problem
with relative path usage? I'll have to continue investigating.
Sam.
>
> Thanks,
> -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
--
Sam Spilsbury
--
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
