summaryrefslogtreecommitdiffstats
path: root/Source/cmComputeLinkDepends.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Fix link line order when shared libraries are de-duplicatedDaniele E. Domenichelli2014-11-101-4/+9
| | | | | | | | | | | | | | | | | | | | Since commit v3.1.0-rc1~227^2~1 (De-duplicate shared library targets in generated link lines, 2014-07-30) we de-duplicate shared library targets on the link line. However, some toolchains will fail linking if an executable is linking to a shared library that is not used directly and a static library that depends on the shared one. The linker may not keep the reference to the shared library the first time and then the symbols needed by the static library may not be found. Fix this by reversing the direction of the for loop that removes the duplicate shared libraries, in order to ensure that the last occurrence of the library is left instead of the first one. Extend Tests/Dependency with a case covering this behavior. Create an executable that links to a shared library and a static library but only needs the shared library as a dependency of the static library. Co-Author: Brad King <brad.king@kitware.com>
* De-duplicate shared library targets in generated link linesBrad King2014-07-301-2/+13
| | | | | | | | | | The linker will bring in shared libraries as a whole and use them even for symbols that are needed by entries later in the link line. Therefore we do not need to repeat them. De-duplicate link entries that we know are shared libraries because we have a cmTarget associated with them. Tested-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
* cmComputeLinkDepends: Convert AddLinkEntries to a templateBrad King2014-07-071-2/+3
| | | | | Allow the method to be called with a vector of any type that can be converted to cmLinkItem.
* cmTarget: Lookup targets in LinkInterface and LinkImplementationBrad King2014-06-231-24/+22
| | | | | | | | | | | | | | | Instead of storing just the string names in these structures, lookup any target associated with each item and store its cmTarget pointer. Use the cmLinkItem class to hold the name and pointer together. Update client sites to use the pre-stored lookup result instead of looking up the target name again. Create a cmTarget::LookupLinkItems helper method to handle the lookup. Since lookups are now moving from cmComputeLinkDepends::AddLinkEntries to cmTarget::LookupLinkItems, move use of CheckCMP0004 to the latter. This drops use of CheckCMP0004 from entries added for _LIB_DEPENDS variables by cmComputeLinkDepends::AddVarLinkEntries, but I do not think that use was intentional originally anyway.
* cmTarget: Add method to lookup other targets in a target's scopeBrad King2014-06-231-28/+3
| | | | | Move the main implementation of cmComputeLinkDepends::FindTargetToLink into cmTarget.
* cmTarget: Remove 'head' argument from GetLinkImplementationBrad King2014-06-231-1/+1
| | | | | | | | | | | | | Many of the 'head' arguments added by commit v2.8.11~289^2~1 (Make linking APIs aware of 'head' target, 2013-01-04) turned out not to be needed. The "link implementation" of a target never needs to be computed with anything but itself as the 'head' target (except for CMP0022 OLD behavior because then it is the link interface). Remove the unused 'head' target paths. Add "internal" versions of cmTarget::GetDirectLinkLibraries and GetLinkImplementationLibraries to support the CMP0022 OLD behavior without otherwise exposing the 'head' target option of these methods.
* cmComputeLinkInformation: Remove 'head' argumentBrad King2014-06-231-7/+5
| | | | | | It is only ever constructed with the current target as its own 'head'. Co-Author: Stephen Kelly <steveire@gmail.com>
* cmComputeLinkDepends: Simplify CheckWrongConfigItem implementationBrad King2014-06-231-6/+3
| | | | Combine the outer two if() conditions into a single one with &&.
* Remove some c_str() calls.Stephen Kelly2014-03-111-5/+5
| | | | | | Use the clang RemoveCStrCalls tool to automatically migrate the code. This was only run on linux, so does not have any positive or negative effect on other platforms.
* stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-3/+4
|
* strings: Remove cmStdString referencesBen Boeckel2014-03-081-5/+5
| | | | | | | | | | | Casts from std::string -> cmStdString were high on the list of things taking up time. Avoid such implicit casts across function calls by just using std::string everywhere. The comment that the symbol name is too long is no longer relevant since modern debuggers alias the templates anyways and the size is a non-issue since the underlying methods are generated since it's inherited.
* stringapi: Use strings in target nameBen Boeckel2014-03-081-4/+5
|
* Constify handling of link targets.Stephen Kelly2013-12-111-5/+6
|
* cmTarget: Make GetProperty() const.Stephen Kelly2013-10-311-1/+2
| | | | | | This has follow-on effects for other methods and classes. Further work on making the use of const cmTarget pointers common can be done, particularly with a view to generate-time methods.
* Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-071-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This target type only contains INTERFACE_* properties, so it can be used as a structural node. The target-specific commands enforce that they may only be used with the INTERFACE keyword when used with INTERFACE_LIBRARY targets. The old-style target properties matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for this target type. The name of the INTERFACE_LIBRARY must match a validity generator expression. The validity is similar to that of an ALIAS target, but with the additional restriction that it may not contain double colons. Double colons will carry the meaning of IMPORTED or ALIAS targets in CMake 2.8.13. An ALIAS target may be created for an INTERFACE library. At this point it can not be exported and does not appear in the buildsystem and project files are not created for them. That may be added as a feature in a later commit. The generators need some changes to handle the INTERFACE_LIBRARY targets returned by cmComputeLinkInterface::GetItems. The Ninja generator does not use that API, so it doesn't require changes related to that.
* Make linking APIs aware of 'head' targetStephen Kelly2013-01-081-5/+6
| | | | | | | | | | | The 'head' is the dependent target to be linked with the current target. It will be used to evaluate generator expressions with proper handling of mapped configurations and is used as the source target of properties. This requires that memoization is done with a key of a pair of target and config, instead of just config, because now the result also depends on the target. Removing the memoization entirely is not an option because it slows cmake down considerably.
* Add OBJECT_LIBRARY target typeBrad King2012-03-131-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | This library type can compile sources to object files but does not link or archive them. It will be useful to reference from executable and normal library targets for direct inclusion of object files in them. Diagnose and reject the following as errors: * An OBJECT library may not be referenced in target_link_libraries. * An OBJECT library may contain only compiling sources and supporting headers and custom commands. Other source types that are not normally ignored are not allowed. * An OBJECT library may not have PRE_BUILD, PRE_LINK, or POST_BUILD commands. * An OBJECT library may not be installed, exported, or imported. Some of these cases may be supported in the future but are not for now. Teach the VS generator that OBJECT_LIBRARY targets are "linkable" just like STATIC_LIBRARY targets for the LinkLibraryDependencies behavior.
* Run vim spellcheck on some filesYury G. Kudryashov2012-02-291-3/+3
|
* Tolerate cycles in shared library link interfaces (#12647)Brad King2012-01-131-3/+19
| | | | | | | | | | | | | Since commit 183b9509 (Follow all dependencies of shared library private dependencies, 2011-12-14) we honor LINK_INTERFACE_LIBRARIES when following dependent shared libraries. The link interface properties may form a cycle if set incorrectly by a project. Furthermore, the property LINK_DEPENDENT_LIBRARIES may form a cycle if set incorrectly by hand (though CMake should never generate one). In either case, do not follow the cycle forever when following the dependent shared library closure. We only need to add dependency edges to the constraint graph once. Add "LinkInterfaceLoop" test to cover this case.
* Follow all dependencies of shared library private dependenciesBrad King2011-12-141-1/+2
| | | | | | | | | In cmComputeLinkDepends we compute the transitive closure of private shared library dependencies. When a shared library is added to this closure we must follow all of its dependencies whether they are private or public. Previously we only followed the private dependencies. Fix the implementation to follow the public dependencies too. Also extend the ExportImport test to cover this case.
* Documentation: Fix spelling / formatting errors (#12287)Modestas Vainius2011-06-191-1/+1
| | | | | | | | | | | | | | The patch fixes the following problems spotted by lintian: W: cmake-data: manpage-has-errors-from-man usr/share/man/man1/cmakemodules.1.gz 2641: warning [p 39, 1.5i]: can't break line I: cmake-data: spelling-error-in-manpage usr/share/man/man1/cmakeprops.1.gz explict explicit I: cmake: spelling-error-in-binary usr/bin/cmake explict explicit I: cmake: spelling-error-in-binary usr/bin/cpack explict explicit I: cmake: spelling-error-in-binary usr/bin/ctest explict explicit W: cmake: manpage-has-errors-from-man usr/share/man/man1/cmake.1.gz 7300: warning [p 120, 3.3i]: can't break line I: cmake: spelling-error-in-manpage usr/share/man/man1/cmake.1.gz explict explicit I: cmake-curses-gui: spelling-error-in-binary usr/bin/ccmake explict explicit I: cmake-qt-gui: spelling-error-in-binary usr/bin/cmake-gui explict explicit
* Distinguish "strong" and "weak" target dependency edgesBrad King2010-08-251-1/+2
| | | | | | Utility dependencies are "strong" because they must be enforced to generate a working build. Link dependencies are "weak" because they can be broken in the case of a static library cycle.
* Split notion of node lists and edge listsBrad King2010-08-251-10/+10
|
* Convert CMake to OSI-approved BSD LicenseBrad King2009-09-281-14/+9
| | | | | | | This converts the CMake license to a pure 3-clause OSI-approved BSD License. We drop the previous license clause requiring modified versions to be plainly marked. We also update the CMake copyright to cover the full development time range.
* Define 'multiplicity' for cyclic dependenciesBrad King2009-09-011-1/+22
| | | | | | | | | We create target property "LINK_INTERFACE_MULTIPLICITY" and a per-config version "LINK_INTERFACE_MULTIPLICITY_<CONFIG>". It sets the number of times a linker should scan through a mutually dependent group of static libraries. The largest value of this property on any target in the group is used. This will help projects link even for extreme cases of cyclic inter-target dependencies.
* ENH: Introduce cmTarget::LinkImplementation APIBrad King2009-07-081-14/+7
| | | | | | | | The new method centralizes loops that process raw OriginalLinkLibraries to extract the link implementation (libraries linked into the target) for each configuration. Results are computed on demand and then cached. This simplifies link interface computation because the default case trivially copies the link implementation.
* ENH: Simplify cmTarget link interface storageBrad King2009-07-071-2/+2
| | | | | This makes the LinkInterface struct a member of cmTarget, pimplizes the config-to-interface map, and stores interface instances by value.
* ENH: Centralize default link interface computationBrad King2009-07-061-14/+13
| | | | | | When LINK_INTERFACE_LIBRARIES is not set we use the link implementation to implicitly define the link interface. These changes centralize the decision so that all linkable targets internally have a link interface.
* ENH: Move CMP0004 check into cmTargetBrad King2009-07-061-61/+1
| | | | | | This moves code implementing policy CMP0004 into cmTarget::CheckCMP0004. The implementation is slightly simpler and can be re-used outside of cmComputeLinkDepends.
* BUG: Lookup transitive link deps in depender scopeBrad King2009-04-061-11/+23
| | | | | | | The transitive link dependencies of a linked target must be followed in its own scope, not in the scope of the original target that depends on it. This is necessary since imported targets do not have global scope. See issue #8843.
* ENH: Allow a custom list of debug configurationsBrad King2008-09-041-16/+3
| | | | | | Create a DEBUG_CONFIGURATIONS global property as a way for projects to specify which configuration names are considered to be 'debug' configurations.
* BUG: Link flags should still be chainedBrad King2008-08-291-4/+1
| | | | | | | The recent fix to avoid including flags in dependency inferral also dropped them from chaining of dependencies through targets. This fix restores chaining of flags through known dependency lists while still leaving them out of inferred dependency lists.
* BUG: A -framework Foo is also a libBrad King2008-08-291-1/+2
|
* BUG: Fix previous fix.Brad King2008-08-291-1/+1
|
* BUG: When recognizing flags on link lines, we must still treat -l as a library.Brad King2008-08-291-1/+1
|
* ENH: New link line item ordering algorithmBrad King2008-08-271-148/+218
| | | | | | | | | This change introduces a new algorithm for link line construction. The order it computes always begins with the exact link line specified by the user. Dependencies of items specified by the user are tracked, and those that are not already satisified by the line are appended to it at the end with minimal repeats. This restores the behavior of CMake 2.4 and below while still fixing some of its bugs. See issue #7546.
* BUG: Do not infer dependencies of link flagsBrad King2008-08-271-3/+10
| | | | | | | In cmComputeLinkDepends link items that look like flags (starting in '-') should not be included in dependency inferral. They are not libraries and therefore have no dependencies. They should just be passed through to the final link line unchanged. See issue #7546.
* BUG: Treat empty config name as no configurationBrad King2008-08-271-1/+1
| | | | | In cmComputeLinkDepends we should treat an empty configuration name as equivalent to no specific configuration at all.
* ENH: Add UNKNOWN type for IMPORTED librariesBrad King2008-08-181-2/+10
| | | | | | | | | | | | | | | When creating an IMPORTED target for a library that has been found on disk, it may not be known whether the library is STATIC or SHARED. However, the library may still be linked using the file found from disk. Use of an IMPORTED target is still important to allow per-configuration files to be specified for the library. This change creates an UNKNOWN type for IMPORTED library targets. The IMPORTED_LOCATION property (and its per-config equivalents) specifies the location of the library. CMake makes no assumptions about the library that cannot be inferred from the file on disk. This will help projects and find-modules import targets found on disk or specified by the user.
* BUG: Avoid bogus dependency on executable targetsBrad King2008-08-061-3/+22
| | | | | | | | | | | | When an executable target within the project is named in target_link_libraries for another target, but the executable does not have the ENABLE_EXPORTS property set, then the executable cannot really be linked. This is probably a case where the user intends to link to a third-party library that happens to have the same name as an executable target in the project (or else will get an error at build time). We need to avoid making the other target depend on the executable target incorrectly, since the executable may actually want to link to that target and this is not a circular depenency.
* BUG: Preserve all non-targets on user link linesBrad King2008-07-301-19/+2
| | | | | | | | | | | | | | | | | | | | | In CMake 2.4 the generated link line for a target always preserved the originally specified libraries in their original order. Dependencies were satisfied by inserting extra libraries into the line, though it had some bugs. In CMake 2.6.0 we preserved only the items on the link line that are not known to be shared libraries. This reduced excess libraries on the link line. However, since we link to system libraries (such as /usr/lib/libm.so) by asking the linker to search (-lm), some linkers secretly replace the library with a static library in another implicit search directory (developers can override this by using an imported target to force linking by full path). When this happens the order still matters. To avoid this and other potential subtle issues this commit restores preservation of all non-target items and static library targets. This will create cases of unnecessary, duplicate shared libraries on the link line if the user specifies them, but at least it will work. In the future we can attempt a more advanced analysis to safely remove duplicate shared libraries from the link line.
* BUG: Preserve shared lib order for 2.4 compatibilityBrad King2008-07-301-2/+7
| | | | | | | | We preserve the order and multiplicity of libraries directly linked by a target as specified by the user. Items known to be shared libraries may be safely skipped because order preservation is only needed for static libraries. However, CMake 2.4 did not skip shared libs, so we do the same when in 2.4 compatibility mode.
* ENH: When preserving potentially static portions of original user link lines ↵Brad King2008-04-301-2/+14
| | | | recognize shared library names by their extension and skip them.
* BUG: Fix preservation of static libraries on original link lines.Brad King2008-04-231-6/+68
|
* ENH: Simplify link lines in some cases by not allowing targets to be ↵Brad King2008-04-231-1/+9
| | | | inferred dependees of items with unknown dependencies.
* BUG: Fix bug 6605 more completelyBrad King2008-03-311-0/+37
| | | | | | - CMake 2.4 added link directories for targets linked in the optimized configuration even when building debug - Old behavior for policy CMP0003 must account for this
* ENH: Add policy CMP_0004 to require library names to have no leading or ↵Brad King2008-03-131-11/+41
| | | | trailing whitespace. Replace previous check of CMAKE_BACKWARDS_COMPATIBILITY against version 2.4 with the policy.
* COMP: Fix Borland 5.5 buildBrad King2008-02-241-5/+5
| | | | | | | - Its <iosfwd> header includes windows.h which defines GetCurrentDirectory - It defines 'interface' so we cannot use it as a variable name.
* BUG: Update cmComputeLinkDepends to support leading/trailing whitespace ↵Brad King2008-02-131-2/+35
| | | | stripping off link items for compatibility.
* BUG: Fix cmComputeLinkDepends::AddVarLinkEntriesBrad King2008-02-111-1/+31
| | | | | - Track link type correctly - Use _LINK_TYPE variables exported by CMake 2.4
generated by cgit v0.12 at 2024-09-15 01:45:58 (GMT)