A few pieces of code have some ambiguous type deduction that seems to
resolve correctly for most compilers but not for the Oracle compiler.
This makes those few instances more explicit.
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>
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>
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This moves code implementing policy CMP0004 into cmTarget::CheckCMP0004.
The implementation is slightly simpler and can be re-used outside of
cmComputeLinkDepends.
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.
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.
Stephen Kelly
Brad King
Chuck Atkins
Daniele E. Domenichelli
Ben Boeckel
Yury G. Kudryashov
Modestas Vainius