57f03e59 Port some of the cmExportFileGenerator API to cmGeneratorTarget.
57ab0f70 Port cmExportBuildFileGenerator to cmGeneratorTarget.
570938cb cmExportTryCompileFileGenerator: Create cmGeneratorTargets.
ec38e4c8 Move GetFullPath to cmGeneratorTarget
dfb025bf Move GetLocationForBuild to cmGeneratorTarget.
9f2dca80 Move GetLocation to cmGeneratorTarget.
c7a8e74b Always access target location from a cmGeneratorTarget instance.
5b60eaf6 cmTarget: Restore the ImportedGetLocation method.
50b17a61 cmIncludeCommand: Populate the cmGeneratorTargets in deprecated path.
ba266858 cmTarget: Create cmGeneratorTargets before reading deprecated LOCATION.
5ab3a946 cmTarget: Inline GetLocation into deprecated callers.
496f4cd0 cmGlobalGenerator: Create cmGeneratorTargets before QtAutomoc.
de80993a cmGlobalGenerator: Create cmGeneratorTargets earlier.
611220f7 cmTarget: Use reliable test for CMP0024 and CMP0026 OLD.
bbad6ba5 cmLocalGenerator: Remove unused AddCustomCommandToCreateObject method.
e4dc83ad cmLocalGenerator: Remove unused AddBuildTargetRule method.
...
Since commit v3.3.0-rc1~62^2~5 (cmTarget: Store only cmListFileContext
for CMP0023 handling, 2015-05-18) a call to target_link_libraries on a
target that was defined in another (non-ancestor) directory crashes
because no execution context is left active. Fix this by getting the
execution context from the actual cmMakefile where the current
target_link_libraries call takes place. Test this by verifying that
such calls correctly produce an error diagnostic instead of crashing.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN were first
merged in commit v2.8.12~322 (Merge topic 'VISIBILITY_PRESET-property',
2013-06-05) but worked only for shared libraries and executables with
exports. Prior to commit v3.0.0-rc1~581^2 (GenerateExportHeader:
Deprecate add_compiler_export_flags function., 2013-09-02) the
add_compiler_export_flags function was used to add visibility flags to
all targets.
The visibility flags are useful for sources in all target types because
they may be later linked into shared libraries or executables with
exports. Introduce policy CMP0063 to enable them for all target types
while preserving compatibility with existing projects that do not expect
this.
d7923b82 Use std::unordered_map instead of hash_map where available.
820777af Tests: Don't rely on ordering of targets in maps.
921d74d8 AutoGen: Don't iterate over a container while populating it.
When CMP0003 was first introduced we wanted to link all libraries by
full path. However, some projects had problems on platforms where
find_library would find /usr/lib/libfoo.so when the project really
wanted to link to /usr/lib/<arch>/libfoo.so and had been working by
accident because pre-CMP0003 behavior used -lfoo to link.
We first tried to address that in commit v2.6.0~440 (Teach find_library
to avoid returning library paths in system directories, 2008-01-23) by
returning just "foo" for libraries in implicit link directories. This
caused problems for projects expecting find_library to always return a
full path. We ended up using the solution in commit v2.6.0~366 (...
switch library paths found in implicit link directories to use -l,
2008-01-31). However, the special case for libraries in implicit link
directories has also proven problematic and confusing.
Introduce policy CMP0060 to switch to linking all libraries by full path
even if they are in implicit link directories. Explain in the policy
documentation the factors that led to the original approach and now to
this approach.
a9c9b66c cmTarget: use a hash_map for cmTargets typedef
bcb6dbc1 cmTarget: help the optimizer a bit
679f3dee cmTarget: use hash_set for sets of strings
23d6520d cmTarget: Allow caching of empty genex expansions
cd54f1db cmTarget: Only copy GenEx expansions when necessary
b75fc0e1 cmTarget: Don't set properties on custom targets
66076915 cmTarget: Use static strings for special property names
cebefa71 cmTarget: Sort special property checks
97ce676e cmTarget: Fast path for regular properties
4cfa918a cmTarget: Factor out common code
85242b7d cmTarget: Use else/if trees rather than an if tree
Replace isLinkDependentProperty with a CompatibleInterfaces structure
that records all the compatible interface properties in a set for each
type. This avoids repeatedly traversing the link implementation closure
and asking every target for its compatible interface properties.
Split the library lists out of LinkImplementation and LinkInterface into
LinkImplementationLibraries and LinkInterfaceLibraries parent classes,
respectively. Return these from GetLinkImplementationLibraries and
GetLinkInterfaceLibraries, respectively, so that callers cannot access
parts of the structures that have not been populated.
The old link dependency analysis is now needed only for the VS 6
generator code delimited by CM_USE_OLD_VS6 to support project-provided
project templates. Rename the related cmTarget members to be "ForVS6".
Implementation of CMP0027 OLD behavior needs to know whether each entry
in LinkImplementation::Libraries came from a generator expression or
not. Add a FromGenex member to cmLinkImplItem to record this.
Create a cmLinkImplItem class derived from cmLinkItem so more
information can be added to link implementation entries than link
interface entries. Convert the LinkImplementation Libraries member to
hold it. Update client sites accordingly.
Add a 'usage_requirements_only' parameter to GetLinkInterfaceLibraries
and supporting internal APIs to pass through to ExpandLinkItems so it
knows whether to use SetTransitivePropertiesOnly while evaluating
generator expressions.
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.
Since commit v2.8.12~437^2~2 (VS: Separate compiler and linker PDB files
2013-04-05) we no longer set /Fd with the PDB_NAME or PDB_OUTPUT_DIRECTORY
properties. Those properties now exclusively handle linker PDB files.
Since STATIC libraries do not link their compiler PDB file becomes more
important. Add new target properties "COMPILE_PDB_NAME[_<CONFIG>]" and
"COMPILE_PDB_OUTPUT_DIRECTORY[_<CONFIG>]" to specify the compiler PDB
file location and pass the value to the MSVC /Fd option.
Add a cmTarget::CompileInfo struct to hold per-configuration information
about the compilation settings in a target. This is different than
cmTarget::OutputInfo because it applies to any targets that can compile
sources even if they do not link or archive.
Replace calls to GetLinkInformation with calls to a method to get only
the target closure, not the link languages etc. The replaced calls
are used while evaluating generator expressions only. This makes
transitive generator expression evaluation independent from
the languages of a target. In a follow-up topic, it will be possible
to make the languages depend on generator expression evaluation, via
evaluation of the SOURCES and INTERFACE_SOURCES target properties.
Because the order of entries is not the same as the final link line,
the order of debug output is different in the RunCMake.CompatibleInterface
test, because the BOOL_PROP7 target property is evaluated first. Adjust
the test to account for that new order.
For the OLD CMP0022 behavior, we need to treat the implementation
as the interface when computing the interface libraries. Make it
possible to do that without computing the link languages by adding
a new GetLinkImplementationLibraries method. Extend the existing
GetLinkImplementation method to populate the languages if the
libraries have already been computed and cached.
Change GetTransitivePropertyTargets to invoke GetLinkInterfaceLibraries
instead of GetLinkInterface. This is key, as it is a method called
by cmGeneratorExpressionEvaluator.
Change the cmGeneratorExpressionEvaluator to invoke
GetLinkImplementationLibraries instead of GetLinkImplementation.
When evaluating the SOURCES property, we will need to be able to access
the link libraries without accessing the link languages, as the languages
depend on the SOURCES.
The callers already skip non-targets, so unify the target search.
Change supporting functions to accept a container of targets instead
of strings where possible.
In a follow-up, the list of sources will become dependent on
the config, so check for existence in cmTarget::GetSourceFiles
instead of up-front with cmGlobalGenerator::CheckTargets().
It accepts a before parameter but is never called with before=true.
compile definitions are sorted by std::set, so it wouldn't make sense
to allow user sorting.
Direct users of IMPORTED targets treat INTERFACE_INCLUDE_DIRECTORIES
as SYSTEM, after commit a63fcbcb (Always consider includes from IMPORTED
targets to be SYSTEM., 2013-08-29). It was intended that transitive
use of an IMPORTED target would have the same behavior, but that
did not work. The implementation processed only direct dependencies
in cmTarget::FinalizeSystemIncludeDirectories.
Implement transitive evaluation of dependencies by traversing the
link interface of each target in the link implementation.
Revert the origin-tracking infrastructure from commit 98093c45 (QtAutoUic:
Add INTERFACE_AUTOUIC_OPTIONS target property., 2013-11-20). Use the
compatibility-tracking for compatible strings instead.
If two different dependencies require different AUTOUIC_OPTIONS,
cmake will now appropriately issue an error.
98093c4 QtAutoUic: Add INTERFACE_AUTOUIC_OPTIONS target property.
02542b4 QtAutoUic: Handle new -include command line parameter.
1242f4e Genex: Add {UPPER,LOWER}_CASE and MAKE_C_IDENTIFIER.
754b321 QtAutogen: Use config without prefix in map key.
Transitively consume the property from linked dependents.
Implement configuration-specific support by following the pattern
set out for compile definitions and includes in cmQtAutoGenerators.
Implement support for origin-tracking with CMAKE_DEBUG_TARGET_PROPERTIES.
This is motivated by the needs of KDE, which provides a separate
translation system based on gettext instead of the Qt linguist
translation system. The Qt uic tool provides command line options
for configuring the method used to translate text, and to add an
include directive to the generated file to provide the method.
http://thread.gmane.org/gmane.comp.kde.devel.frameworks/7930/focus=7992
Implement the interface to provide the uic options as a usage-requirement
on the KI18n target, as designed for KDE.
Diagnostics which check the sanity of exported include paths
previously skipped over any path containing a generator expression.
Introduce a policy to issue an error message in such cases.
The export files created in the OLD behavior are not usable, because
they contain relative paths or paths to the source or build location
which are not suitable for use on installation. CMake will report an
error on import.
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.
It is never used. Presumably it only exists so that a const char * can
be returned from GetLocation. However, that is getting in the way
now, so use a static std::string instead, which is already a common
pattern in cmake.
When using the boost MPL library, one can set a define to increase
the limit of how many variadic elements should be supported. The
default for BOOST_MPL_LIMIT_VECTOR_SIZE is 20:
http://www.boost.org/doc/libs/1_36_0/libs/mpl/doc/refmanual/limit-vector-size.html
If the foo library requires that to be set to 30, and the independent
bar library requires it to be set to 40, consumers of both need to set
it to 40.
add_library(foo INTERFACE)
set_property(TARGET foo PROPERTY INTERFACE_boost_mpl_vector_size 30)
set_property(TARGET foo PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(foo INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_library(bar INTERFACE)
set_property(TARGET bar PROPERTY INTERFACE_boost_mpl_vector_size 40)
# Technically the next two lines are redundant, but as foo and bar are
# independent, they both set these interfaces.
set_property(TARGET bar PROPERTY COMPATIBLE_INTERFACE_NUMBER_MAX boost_mpl_vector_size)
target_compile_definitions(bar INTERFACE BOOST_MPL_LIMIT_VECTOR_SIZE=$<TARGET_PROPERTY:boost_mpl_vector_size>)
add_executable(user)
target_link_libraries(user foo bar)
Because the TARGET_PROPERTY reads the boost_mpl_vector_size property
from the HEAD of the dependency graph (the user target), and because
that property appears in the COMPATIBLE_INTERFACE_NUMBER_MAX of
the dependencies of the user target, the maximum value for it is
chosen for the compile definition, ie, 40.
There are also use-cases for choosing the minimum value of a number.
In Qt, deprecated API can be disabled by version. Setting the
definition QT_DISABLE_DEPRECATED_BEFORE=0 disables no deprecated
API. Setting it to 0x501000 disables API which was deprecated before
Qt 5.1 etc.
If two dependencies require the use of API which was deprecated in
different Qt versions, then COMPATIBLE_INTERFACE_NUMBER_MIN can be
used to ensure that both can compile.
The result is that the depends of the target are created.
So,
add_library(somelib foo.cpp)
add_library(anotherlib EXCLUDE_FROM_ALL foo.cpp)
add_library(extra EXCLUDE_FROM_ALL foo.cpp)
target_link_libraries(anotherlib extra)
add_library(iface INTERFACE)
target_link_libraries(iface INTERFACE anotherlib)
Executing 'make iface' will result in the anotherlib and extra targets
being made.
Adding a regular executable to the INTERFACE of an INTERFACE_LIBRARY
will not result in the executable being built with 'make iface' because
of the logic in cmComputeTargetDepends::AddTargetDepend.
So far, this is implemented only for the Makefile generator. Other
generators will follow if this feature is possible for them.
Make INTERFACE_LIBRARY targets part of the all target by default.
Test this by building the all target and making the expected library
EXCLUDE_FROM_ALL.
The final location and name of a build-target is not determined
until generate-time. However, reading the LOCATION property from
a target is currently allowed at configure time. Apart from creating
possibly-erroneous results, this has an impact on the implementation
of cmake itself, and prevents some major cleanups from being made.
Disallow reading LOCATION from build-targets with a policy. Port some
existing uses of it in CMake itself to use the TARGET_FILE generator
expression.
Stephen Kelly
Brad King
Gregor Jasny
Ben Boeckel
Nils Gladitz
Clinton Stimpson