On 10/23/2012 09:13 AM, Stephen Kelly wrote: > What is 'link-aware code'? A part of the cmake implementation that has rules > specific to linking where the difference between the direct and transitive > dependencies is important?
cmComputeLinkDepends is exclusively responsible for handling transitive link dependencies. It has non-trivial logic that took years to get right. Don't try to replace it with a simple genex-based transitive closure. > However, if the direct and transitive dependencies really must be kept > separate, that will have to be rethought anyway. They do. A few years ago I went through major pain to drop uses of the old GetLinkLibraries and use either GetOriginalLinkLibraries or results from cmComputeLinkDepends wherever possible. It is necessary to keep them separate because cmComputeLinkDepends needs to know exactly what the user originally specified as direct dependencies in order to compute the closure properly. > For example, it makes sense for POSITION_INDEPENDENT_CODE, so Qt5Core should > have INTERFACE_POSITION_INDEPENDENT_CODE ON and the > POSITION_INDEPENDENT_CODE property should be evaluated with EACH as I > pseudo-implemented in my patch. Just like link dependencies I fear the transitive behavior of each build property may need custom C++ code. > I can't think of a reason to link a library based on whether > POSITION_INDEPENDENT_CODE is true or false for a target. A package could provide a PIC and non-PIC version of a library and pick one based on whether the target is PIC or not. > In somewhat more concrete terms, maybe if the STD_CXX11 property ever > becomes a reality, a library built with c++11 might require that downstreams > also use c++11 because of binary compatibility concerns in the stdlib IMO that should be a detect-and-reject case rather than propagated: CMake Error ...: Target foo has STD_CXX11=OFF but links bar with STD_CXX11=ON. Just like PIC and WIN32 a package can provide multiple libraries and select them conditionally on the needs of the final target. I think the general philosophy is that the final target should specify how it wants to build and the libraries it links evaluate their exprs to meet its requirements. If they can't then it is an error. >> We may need a policy implemented with minimum duplication to provide >> the capabilities that export() used to. > > Would the policy be used to determine whether to execute the export() at > configure-time (and strip out any generator expressions found) or at > generate-time (and process the generator expressions)? Something like this, yes. It may be really nasty to know when to trigger the policy because we need to know whether the project loads its own export() output. It may be simpler to define the export() behavior with an explicit option or with CMAKE_MINIMUM_REQUIRED_VERSION. > It still looks like a lot of duplication to me (my commit that moves > HasSOName and all previous commits may need to be copied). Maybe it's not as > bad as it seems though. Policies were first introduced because of the need for CMP0003 after some major internal changes to the way link lines are computed. I actually first had the new link implementation done without any policy. If all projects were written according to our documented behavior then there would have been no need for more work. However, every single major client project at the time (including KDE, ITK, VTK, and ParaView) had cases where things had only been working accidentally due to details of the prior implementation. It took over TWO PERSON MONTHS more work to introduce policies and CMP0003 to make things compatible. This stuff isn't easy. You're talking about fundamental changes to the way CMake processes the most basic and common interfaces used by projects (include dirs, link libs, etc.). -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
