Add a 'usage_requirements_only' parameter to ExpandLinkItems so that it
knows whether to use SetTransitivePropertiesOnly while evaluating
generator expressions. Update existing call sites to pass 'false' since
they are for linking and not usage requirements.
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.
Add a method like GetUtilities but that provides the target names
already looked up and resolved to cmTarget pointers internally. Update
call site in cmComputeTargetDepends::AddTargetDepend to use the
already-found target instead of looking it up again.
Many items named in target_link_libraries calls are targets, but not
all. Create a cmLinkItem type that acts like std::string so it can name
an item but also has a pointer to a cmTarget that is the result of
looking up the item name in the referencing target's scope. This will
be useful to avoid duplicate lookup operations later.
Move generator expression evaluation for imported library lists out of
GetImportInfo and into a new GetImportLinkInterface helper. This avoids
duplicating the computation and storage of all imported target info just
because some of it is parameterized on the 'head' target.
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.
Create an ExpandLinkItems method to handle evaluation of generator
expressions in a library list and expansion of the ;-list into a vector.
Replace some duplicate copies of the implementation with calls to the
new helper.
Allow setting build properties based on the features available
for a target. The availability of features is determined at
generate-time by evaluating the link implementation.
Ensure that the <LANG>_STANDARD determined while evaluating
COMPILE_FEATURES in the link implementation is not lower than that
provided by the INTERFACE of the link implementation. This is
similar to handling of transitive properties such as
POSITION_INDEPENDENT_CODE.
These policies should be checked at the call site that tries to access
the LOCATION or SOURCES property, not the directory scope containing the
target. Thread the caller context through cmTarget::GetProperty to use
for checking the policy setting and emitting a diagnostic with proper
backtrace.
Extend the RunCMake.CMP0026 and RunCMake.CMP0051 tests with
cross-directory cases.
Since commit e5da9e51 (cmTarget: Allow any generator expression in
SOURCES property., 2014-03-18), source files are computed by
true evaluation of generator expressions, including TARGET_OBJECTS.
This evaluation requires the presence of cmGeneratorTarget objects
since commit bf98cc25 (Genex: Evaluate TARGET_OBJECTS as a normal
expression., 2014-02-26).
Ensure that we don't attempt to evaluate the TARGET_OBJECTS generator
expression at configure-time, as can happen if CMP0024 or CMP0026
are OLD. Use old-style parsing of the source item to extract
object target names in that case.
Avoid calling GetProperty("SOURCES") to bypass warnings from CMP0051.
Refactor existing logic in GetLanguages which is similar in intent to
the new GetSourceFiles code.
Allow directories in the source tree or build tree only if the
install tree is a subdirectory of the source tree or build tree,
as appropriate.
Re-use the test files in the RunCMake.include_directories test
to run in multiple scenarios. Bump the required CMake version
in the test to 3.0 to ensure that the new policy warnings are
emitted correctly.
The AddSource method accepts one file and tries to avoiding adding
it to the sources-list of the target if it already exists. This
involves creating many cmSourceFileLocation objects for matching
on existing files, which is an expensive operation.
Avoid the searching algorithm by appending the new sources as one
group. Generate-time processing of source files will ensure
uniqueness.
Add a new AddTracedSources for this purpose. The existing
AddSources method must process the input for policy CMP0049, but
as these source filenames come from cmSourceFile::GetFullPath(),
we can forego that extra processing.
Computing the language involves computing the source files, which
is an expensive operation. It requires calling
cmMakefile::GetOrCreateSource many times, which involves creating
and matching on many cmSourceFileLocation objects.
Source files of a target may depend on the head-target and the
config as of commit e6971df6 (cmTarget: Make the source files depend
on the config., 2014-02-13). The results are cached for each context
as of commit c5b26f3b (cmTarget: Cache the cmSourceFiles in
GetSourceFiles., 2014-04-05).
Each target in the build graph causes language computation of all
of its dependents with itself as the head-target. This means that
for 'core' libraries on which everything depends, the source files
are computed once for every transitive target-level-dependee and
the result is not cached because the head-target is different. This
was observed in the VTK buildsystem.
Short circuit the computation for targets which have a source-list
that is independent of the head-target. If the source-list has
already been computed and the generator expression evaluation
reports that it was context-independent, return the only source-list
already cached for the target. Reset the short-circuit logic when
sources are added and when the link libraries are re-computed.
Extend the interface of the target_compile_features command with
PUBLIC and INTERFACE keywords. Populate the INTERFACE_COMPILER_FEATURES
target property if they are set. Consume the INTERFACE_COMPILER_FEATURES
target property from linked dependent targets to determine the final
required compiler features and the compile flag, if needed.
Use the same pattern of origin-debugging which is used for other
build properties.
Avoid calling AddSource for each src filename. That involves
checking each entry for uniqueness and creating a separate
generator expression for each one.
Instead, add a single entry for the list of sources. The source
files are passed through a uniqueness filter at generate-time, so
duplicates don't matter so much.
Extend the cmGeneratorExpressionDAGChecker with an interface
returning the name of the top target. Use that to determine
when there is a DAG violation, as required by the RunCMake.Languages
tests.
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
This will allow the strings to contain generator expressions.
At this point, generator expressions are still not part of the
SOURCES property when it is read.
When given a non-NULL configuration the GetLocation returned the
location for the given configuration. When given a NULL configuration
the GetLocation method returned a location with the build-system
placeholder for the configuration name. Split the latter use case out
into a separate GetLocationForBuild method and update call sites
accordingly.
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.
Brad King
Stephen Kelly
Ben Boeckel