These use a huge amount of memory that accumulates as generation
proceeds. On the Unix Makefiles generator, only GetIncludeDirectories
and GetCompileDefinitions are even called more than once per target
(once for build files, once for dependency scanning preprocessor info).
Another approach will be needed to avoid duplicate computation in the
cases where it does occur.
These use a huge amount of memory that accumulates as generation
proceeds. On the Unix Makefiles generator, only GetIncludeDirectories
and GetCompileDefinitions are even called more than once per target
(once for build files, once for dependency scanning preprocessor info).
Another approach will be needed to avoid duplicate computation in the
cases where it does occur.
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
7a526c35 VS: Delay getting platform name in local generator
e7fdb44b VS: Delay detection of VS 10 Express 64-bit tools
6e176e6d VS: Delay platform definitions until system name is known
d3d9218a VS: Remove unused method from VS 9 generator
eeb60102 VS: Refactor CMAKE_FORCE_*64 platform definitions
ecb34faa Tell generators about CMAKE_SYSTEM_NAME as soon as it is known
Ask the global generator during generation instead of trying
to store it up front. Later the global generator may not know
the platform name when it is creating the local generator.
Move the definition of CMAKE_VS_PLATFORM_NAME and other variables that
are not needed by CMakeDetermineSystem out of the AddPlatformDefinitions
method and into a SetSystemName method. The latter may later use
CMAKE_SYSTEM_NAME to decide what platform-specific definitions to add.
Remove the general infrastructure for these additional platform
definitions and hard-code the only two special cases that used
it. They are only for historical reasons so no new such cases
should be added.
Add a cmGlobalGenerator::SetSystemName virtual method. Call it from
cmGlobalGenerator::EnableLanguage as soon as CMAKE_SYSTEM_NAME is known.
This will give generators a chance to adapt themselves to the target
system. Pass the cmMakefile instance to the method so that the
generator can update it accordingly. Return early from EnableLanguage
if SetSystemName returns false.
Make blocks adding MS-tool-specific options conditional on a
new "MSTools" boolean member of cmVisualStudio10TargetGenerator.
Hard-code the member to true for now to preserve existing behavior.
The LINK_LIBRARIES property is by *far* the most popular. Move it to the
top. TYPE is second, but with more generator expression usage, that may
change in the future.
10c5c82c Help: Add notes for topic 'generalize-LINK_ONLY'
6e7e881c Honor $<LINK_ONLY> when checking interface properties
0400cd5d Make $<LINK_ONLY> available to projects (#14751)
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.
In cmGeneratorExpressionEvaluator, teach getLinkedTargetsContent to call
cmGeneratorExpression::StripEmptyListElements to transform its return
value so that callers do not have to do so.
In cmGeneratorExpressionEvaluator, avoid searching through the list of
transitive interface property names repeatedly during evaluation of
TargetPropertyNode. Simply record the results of the first search for
later re-use.
In cmGeneratorExpressionEvaluator, make getLinkedTargetsContent a
template so it can traverse over either the Libraries in a cmTarget
LinkImplementationLibraries or a cmTarget LinkInterfaceLibraries. This
also avoids creating a separate vector<cmTarget*>.
Since commit v3.0.0-rc1~174^2~1 (cmTarget: Fix system include annotation
propagation, 2014-01-01) the cmGeneratorTarget::IsSystemIncludeDirectory
method needs to collect all targets that might provide
INTERFACE_(|SYSTEM)_INCLUDE_DIRECTORIES for the current target. We now
have cmTarget::GetLinkImplementationClosure to provide this, so use it.
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.
Callers of cmTarget::GetLinkImplementationClosure are interested in the
set of targets whose interface properties propagate to the current
target. This excludes targets guarded by $<LINK_ONLY>.
Teach the CompatibleInterface test to cover suppression of interface
compatibility tests with $<LINK_ONLY>. Although this is not recommended
in practice, it is a way of covering the above behavior.
Previously this generator expression was used internally by the
target_link_libraries command to honor private linking requirements of
static libraries in their INTERFACE_LINK_LIBRARIES. Remove the check
that limits $<LINK_ONLY> to this use case to make it available for
project code to use too.
Before this commit, you would have to run ctest -S mode to get
MemoryCheckType to work. This is because CMAKE_COMMAND was not set.
The fix is to use cmSystemTools::GetCMakeCommand instead.
This adds support for memory and leak sanitizers. This is built into
clang and gcc 4.8 and new compilers. It is activated with a -f switch
during compile.
8a205b98 cmTarget: Compile old-style link dependencies only for VS 6
d57be904 cmTarget: Run old-style link dependencies only for VS 6
b3b44d13 cmTarget: Rename old-style link dependencies code as "ForVS6"
80cb12bb export_library_dependencies: Use original link libraries internally
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".
This command was using the cmTarget::GetLinkLibraries method with a
comment explaining how execution order gives it the dependencies before
analysis. Just use cmTarget::GetOriginalLinkLibraries instead.
Create the map entry up front and store in it a boolean value indicating
whether the LinkInterface structure has been populated. This approach
leads to shorter code that is easier to follow too.
Create the map entry up front and store in it boolean values indicating
which pieces of the LinkInterface structure have been populated.
This approach leads to shorter code that is easier to follow too.
Fix cmTarget::GetSourceFiles to set EvaluateForBuildsystem on the
$<TARGET_PROPERTY:...,INTERFACE_SOURCES> generator expression so that
the $<TARGET_OBJECTS> generator expression is allowed within an
INTERFACE_SOURCES value.
Extend the InterfaceLibrary test to cover this case. Extend the
RunCMake.TargetObjects test to cover failure of $<TARGET_OBJECTS>
when used through $<TARGET_PROPERTY:...,INTERFACE_SOURCES> in a
non-buildsystem context.
In commit 7b0834e9 (cmTarget: Refactor internal LinkImplementation map,
2014-06-19) cmTarget::GetLinkImplementationLibrariesInternal was changed
accidentally to pass "this" to ComputeLinkImplementation instead of
"head". Change it back.
Teach the VS >= 10 generator to honor flags other than -I and -D
in the CMAKE_RC_FLAGS[_<CONFIG>] variable. Place them within the
ResourceCompile .vcxproj element under AdditionalOptions.
Also add a rudimentary flag map to map '-n' to 'NullTerminateStrings'.
2c470b77 add_library: Allow arbitrary non-linked sources in OBJECT libraries
de4f3e2c Tests: Fix broken dependency in ObjectLibrary test
54bf5858 Tests: Resolve TODO comment left in ObjectLibrary test
This commit adds support for ThreadSanitizer to ctest. ThreadSanitizer
is part of the clang compiler and also gcc 4.8 and later. You have to
compile the code with special flags. Then your code gets the the
ThreadSanitizer ability built into it. To pass options to the
ThreadSanitizer you use an environment variable. This commit teaches
ctest to parse the output from ThreadSanitizer and send it to CDash.
Loosen this restriction on OBJECT libraries to allow source files of any
name to be generated by custom commands or listed for reference in IDE
projects so long as they would not affect linking of a normal library.
Update the rejection message to be more specific about the looser
restriction.
Extend the ObjectLibrary test to cover a ".cmake" file generated by a
custom command in an OBJECT library.
Use the AddInterfaceEntries helper to avoid duplication. In
TargetPropertyEntry, replace the TargetName string member with a
reference to the full cmLinkImplItem that produced the entry. This is
possible because the cmLinkImplItem is available in AddInterfaceEntries
(it was not available in GetIncludeDirectories). Having the full
cmLinkImplItem allows processIncludeDirectories to implement CMP0027 OLD
behavior without repeating the target name lookup.
Update the RunCMake.CompatibleInterface test DebugProperties case
expected output for the new order of the messages.
Evaluate and lookup the target name only once per TargetPropertyEntry
instead of repeating it for each include directory entry. Use a local
checkCMP0027 variable to record whether the policy should be checked.
Evaluate the target name as a generator expression only if it looks like
one. Lookup the target by name only after evaluation of generator
expressions.
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 cmTargetInternals::AddInterfaceEntries method to construct a
$<TARGET_PROPERTY:tgt,INTERFACE_XYZ> generator expression and evaluate
it for every target in the link implementation. This will be useful to
de-duplicate such evaluation for each usage requirement separately.
The new method will soon be used in the implementation of the
INTERFACE_* usage requirement lookup methods (GetSourceFiles,
GetCompileOptions, GetCompileDefinitions, GetCompileFeatures,
GetIncludeDirectories). It is necessary for these methods to determine
whether an expression in LinkImplementationPropertyEntries evaluates to
a target or not because generator expression evaluation reports an error
for non-targets and we construct a $<TARGET_PROPERTY:tgt,INTERFACE_XYZ>
expression for each entry that is a target.
The implementation of each usage requirement currently processes the
LinkImplementationPropertyEntries and evaluates all generator
expressions to determine targets. That is no longer necessary because
GetLinkImplementationLibraries now returns resolved and cached targets
together with their name. Use it to implement AddInterfaceEntries.
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.
Send status messages to the CTest HANDLER_OUTPUT log since they are part
of the script handler output. This also ensures they appear inline with
other test command handler output.
Because the 8bit string encoding in libarchive can be different than
the 8bit string encoding in CMake, change to call the wide version
of libarchive functions. They are different if CMake is configured
to use UTF-8 as the internal encoding.
Create helper functions for some libarchive calls to use wstring
internally on platforms supporting it.
Commit v2.8.11~310^2~1 (Keep track of INCLUDE_DIRECTORIES as a vector of
structs., 2012-11-19) added special case of INCLUDE_DIRECTORIES
for the purpose of origin-tracking of individual entries in the property. It
introduced a bug in that it returned an empty string instead of '0' in the
case that no includes have been set.
Commit v2.8.11~289^2~2 (Handle INTERFACE properties transitively for includes
and defines., 2012-09-23) introduced transitive handling of the property
through the link implementation, together with a whitelist of properties
which would be evaluated transitively. Because of the bug introduced
previously, the 'prop' in TargetPropertyNode is non-null,
meaning that the content (the empty string) would be evaluated as a generator
expression. This was harmless as the follow-up code was only for 'INTERFACE_'
variants of target properties, so the effect was the same.
Commits v2.8.11~280^2~2 (Keep track of properties used to determine linker
libraries., 2012-11-05) and v2.8.11~280^2~1 (Add API to calculate
link-interface-dependent bool properties or error., 2013-01-06) added a way
to track and report errors on properties which both determine and are
determined by the link implementation. This was later used in generator
expression evaluation by commit v2.8.11~252^2~2 (Make INTERFACE determined
properties readable in generator expressions., 2013-01-19). If a property
is unset (null), and the link implementation of the target was not being
evaluated, this commit made it possible to evaluate the property from the
link implementation instead. If the link implementation was being evaluated,
an empty string was returned from the generator expression evaluation, which
might be later reported as an error.
The above logic was written for 'compatible interface' properties, but in
fact it should have also included other properties. Because of the
empty-string-instead-of-null bug, this code block is not entered for the
INCLUDE_DIRECTORIES property. At this point, however, the bug still does
not significantly affect behavior, because the follow-up code is still a
no-op for the INCLUDE_DIRECTORIES property, and an empty string is returned
regardless. Commit v2.8.11~189^2~6 (Use the link information as a source of
compile definitions and includes., 2013-02-12) refactored the logic, but also
without a change in behavior.
Commit v2.8.11~156^2~2 (Expand includes and defines transitively
in 'external' genexes., 2013-02-13) refactored the logic again, this time with
a change of behavior. The INCLUDE_DIRECTORIES property was then mapped to
INTERFACE_INCLUDE_DIRECTORIES during transitive generator expression
evaluation. Because the transitive evaluation involved evaluation of the
link implementation, this introduced a recursive loop and a segfault with
code like:
add_library(empty1 ...)
add_library(empty2 ...)
target_link_libraries(empty1
PRIVATE
$<$<STREQUAL:$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>,/foo/bar>:empty2>
)
As there is no real use-case for reading a target property like that while
evaluating the link implementation, this went unnoticed. The same pattern
was followed for other special-cased reads of transitive target properties
such as COMPILE_DEFINITIONS.
The segfault was fixed in the parent commit, but change the property to
return null when appropriate for other future uses.
Commit v2.8.11~156^2~2 (Expand includes and defines transitively
in 'external' genexes., 2013-02-13) introduced a recursive loop
and a stack overflow during evaluation of a link implementation
which depends on a transitive property, such as
add_library(empty1 ...)
add_library(empty2 ...)
target_link_libraries(empty1
PRIVATE
$<$<STREQUAL:$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>,/foo/bar>:empty2>
)
There is no use-case for code like that currently, but it should not
cause a stack overflow.
Avoid the recursion by reporting an error early if a case like this
is found.
A library or executable target that consists only of a reference to an
object library may have no sources to compile or custom commands to run.
The command in the target is the link (or archive) command. Add missing
order-only dependencies to link commands so that target ordering
dependencies are satisfied for it without depending on an intermediate
compilation rule.
Extend the ObjectLibrary test to cover this case.
Co-Author: Brad King <brad.king@kitware.com>
f0e298ad Help: Add notes for topic 'vs14-generator'
5c105140 Tests: Simplify LoadCommand tests
b1cbd577 FindBoost: Add -vc140 mangling for VS 14
bdc7d9c8 VS14: Fix Cl and Link flag tables as previous versions
d96b3f68 VS14: Generate flag tables from MSBuild v140 tool files
65624c39 VS14: Add Visual Studio 14 generator (#14982)
8635ac23 Tests/Preprocess: Remove unnecessary VS version tests
Ninja generator ensures that all custom commands being target
dependencies are run before other source compilations. However in case
there are no such dependencies it currently generates empty phony rules
which clutter the build graph.
Teach the Ninja generator to produce such rules only when necessary.
Actually custom command can write wherever it wants to, such as temporary
folder or source folder, possibly violating rules that only build folder should
be affected. Therefore we should consider custom command dependency at any path
as possible side effect adding phony rule.
We avoid adding phony rules for regular source files (since the paraent
commit) so we no longer need the in-build-tree test to avoid them.
Since commit v2.8.12~248^2 (Ninja: Custom Command file depends don't
need to exist before building, 2013-06-07) all explicit dependencies
inside build folder were considered as possible build command
side-effects and phony rules were produced for them in case they don't
exist when starting to build. This is unnecessary since regular compile
inputs need to exist or cmake will fail. Moreover the exception for
sources having GENERATED property that can be missing is already handled
by WriteAssumedSourceDependencies.
This fixes unwanted phony rules for all regular source files when doing
in-source build, causing Ninja not complain when such files gets missing,
i.e. during development. Also this reduces number of rules in ninja.build.
Now only custom command dependencies are considered as possible side-effects.
24637979 cmTarget: Refactor ComputeLinkImplementation
7812d2a9 cmTarget: Pre-indent a block in ComputeLinkImplementation
f48d8bd6 cmTarget: Shorten a long line in ComputeLinkImplementation
7b0834e9 cmTarget: Refactor internal LinkImplementation map
b8651d97 cmTarget: Remove unnecessary 'mutable' markup
0192be51 cmTarget: De-duplicate link interface evaluation for $<LINK_ONLY>
6ead631b cmTarget: Teach GetLinkInterfaceLibraries to support $<LINK_ONLY>
b030a7f1 cmTarget: De-duplicate link interface genex code for $<LINK_ONLY>
1001490d cmTarget: Teach ExpandLinkItems how to support $<LINK_ONLY>
Apply the flag table fixes from:
commit 9c7f234c (VS: Fix /MANIFESTUAC:NO linker option mapping, 2014-05-07)
commit e8633e66 (VS: Fix /analyze:log flag mapping, 2014-04-01)
commit f2caf795 (VS: Fix /MAP:mapfile flag mapping, 2013-07-09)
to the VS 14 flag tables.
Run cmparseMSBuildXML.py on cl.xml, lib.xml, and link.xml to generate
our flag tables:
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/cl.xml" > cmVS14CLFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/lib.xml" > cmVS14LibFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/link.xml" > cmVS14LinkFlagTable.h
Fix up the declaration names at the top of each file. Finally, teach
cmVisualStudio10TargetGenerator to select the version of the table
matching the version of VS.
Co-Author: Pawel Stopinski <diokhan@go2.pl>
Call the generator "Visual Studio 14" without any year because this
version of VS does not provide a year in the product name.
Copy cmGlobalVisualStudio12Generator to cmGlobalVisualStudio14Generator
and update version numbers accordingly. Add the VS14 enumeration value.
Teach the platform module Windows-MSVC to set MSVC14 and document the
variable. Teach module InstallRequiredSystemLibraries to look for the VS
14 runtime libraries.
Teach tests CheckCompilerRelatedVariables, VSExternalInclude, and
RunCMake.GeneratorToolset to treat VS 14 as they do VS 10, 11, and 12.
Co-Author: Pawel Stopinski <diokhan@go2.pl>
Since commit v3.0.0-rc1~374^2 (Refactor internal resource location APIs
and initialization, 2013-11-07) a bootstrap-built "cmake" tries to
reference "ctest" and "cpack" executables next to itself, which never
exist. Teach cmSystemTools::FindCMakeResources, when bootstrap-built,
to refer to the "ctest" and "cpack" executables in the location where
they will be built after "make".
f5c18c9c cmTarget: Drop GetDirectLinkLibraries methods
281eb3d8 cmTarget: Improve HaveBuildTreeRPATH implementation
d912220e cmTarget: Lookup targets in LinkInterface and LinkImplementation
edce4351 cmExportFileGenerator: Make SetImportLinkProperty a template
097be413 cmTarget: Add GetUtilityItems to get target ordering dependencies
4dad5fd2 cmTarget: Add cmLinkItem to refer to a target by name and pointer
a2723442 Fix scope of transitive target name lookups
069d60fe cmTarget: Add method to lookup other targets in a target's scope
47ab3ca6 cmTarget: Constify GetLinkImplementationClosure results
9f3ed029 cmTarget: Constify GetTransitivePropertyTargets results
6f0951af cmTarget: Drop 'head' target from GetImportInfo
0dc9e88d cmTarget: Remove 'head' argument from GetLinkImplementation
4ac72455 cmTarget: Drop 'head' argument from GetLinkClosure
bcdb7ff9 cmTarget: Remove 'head' argument from GetLinkerLanguage
bd9b667b cmComputeLinkInformation: Remove 'head' argument
06328dd5 cmTarget: Remove 'head' argument from GetLinkInformation
...
The ctest launcher code did not respect the number of errors and
warnings limits. Limit the number of launcher report fragments that we
report in the final submission.
Use LinkImplementationPropertyEntries directly instead of asking
GetProperty to construct a string for LINK_LIBRARIES. This gives us
access to the entry backtraces.
If ComputeLinkImplementationLanguages were ever to cause
GetLinkImplementationLibraries to be invoked then a LinkImplMap entry
may appear in the middle of computing it in GetLinkInformation. Instead
create the map entry up front and store in it boolean values indicating
which pieces of the LinkImplementation structure have been populated.
This approach leads to shorter code that is easier to follow too.
Members of the cmTargetInternals structure do not need to be made
'mutable' even to cache data because there is no reason for the
internal methods to be 'const'.
Teach GetTransitivePropertyTargets to use the GetLinkInterfaceLibraries
method with usage_requirements_only==true instead of evaluating the
INTERFACE_LINK_LIBRARIES property directly. This avoids duplicate
evaluations and makes use of the caching done by
GetLinkInterfaceLibraries.
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.
Simplify the implementation of GetTransitivePropertyTargets by using
ExpandLinkItems with usage_requirements_only==true to evaluate the
generator expressions in the link interface for us.
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.
Since commit 6557382d (stringapi: Use strings for program
paths, 2014-02-24), cmGlobalGenerator::GenerateBuildCommand
takes the make program path as a std::string. Fix the lookup
in cmCPackGenerator::InstallProjectViaInstallCMakeProjects to
use GetSafeDefinition for CMAKE_MAKE_PROGRAM to avoid possible
construction of std::string from a NULL.
Reported-by: Richard Wirth <richard@califax.de>
Installing large directories, e.g., the output of a doxygen run, prints
one line per file resulting in too much noise in the build output. Add
an option to the install(DIRECTORY) command to not print anything upon
make install.
Extend the RunCMake.install test with cases covering MESSAGE_NEVER
behavior of the install(DIRECTORY) command.
Suggested-by: Stefan Eilemann <Stefan.Eilemann@epfl.ch>
Create a variable to allow users to control which installation
messages are printed. In particular, provide a "LAZY" setting
that prints "Installing" messages but not "Up-to-date" messages.
This is desirable for incremental re-installations.
Suggested-by: J Decker <d3ck0r@gmail.com>
Create a cmInstallGenerator::MessageLevel enumeration for future use in
specifying install message verbosity. Thread values of the type through
constructors and save the value as a member of cmInstallGenerator.
Use only a "MessageDefault" value for now.
Create options "MESSAGE_ALWAYS", "MESSAGE_LAZY", and "MESSAGE_NEVER" to
specify whether to print the "Installing" and "Up-to-date" messages.
Extend the RunCMake.file test with cases covering these options.
Teach cmFileCopier::InstallDirectory to detect whether the destination
directory exists. If so, report it as "Up-to-date" instead of
"Installing". This resolves message asymmetry with file installations.
Extend the RunCMake.file and RunCMake.install tests to check the
installation output on both the first and second run.
Suggested-by: J Decker <d3ck0r@gmail.com>
When installing a DIRECTORY, do not pre-create the DESTINATION. The
cmFileCopier::InstallDirectory method will create the directory anyway.
Give it a chance to detect whether the directory already exists or not.
Extend the cmake command-line interface to support
cmake -E env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...
This will be useful to run processes with modified environments
without using a shell or a full "cmake -P" script to wrap it.
Extend the RunCMake.CommandLine test to cover success and failure cases.
Inspired-by: Jonathan Bohren <jbo@jhu.edu>
From the GCC 4.9 release notes for Fortran:
https://gcc.gnu.org/gcc-4.9/changes.html
"Module files: The version of the module files (.mod) has been
incremented; additionally, module files are now compressed."
Teach cmDependsFortran::ModulesDiffer to look for the gzip magic numbers
at the beginning of the module file. If found, assume the module was
produced by gfortran >= 4.9. The modules do not appear to contain the
date as earlier versions did so we can compare the content directly
and do not actually need to decompress.
Since commit 84fdc9921 (stringapi: Pass configuration names as strings,
2014-02-09), it is not safe to use GetDefinition("CMAKE_BUILD_TYPE")
without checking the return value. Use GetSafeDefinition instead so
that a missing definition is treated as an empty string like code paths
did prior to the above commit.
Reported-by: Richard Wirth <richard@califax.de>
Use GetLinkImplementationLibraries instead of GetDirectLinkLibraries
because it tells us whether there will be any libraries to link after
evaluating generator expressions. Also GetDirectLinkLibraries will be
dropped soon.
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.
In cmTarget, cmGeneratorTarget, and cmGeneratorExpressionEvaluator, fix
target name lookups to occur in the cmMakefile context of the target
that referenced the name, not the current 'head' target. The context
matters for imported targets because they are directory-scoped instead
of globally unique. We already do this in cmComputeLinkDepends and
cmComputeTargetDepends.
Extend the InterfaceLibrary test with an example covering this behavior.
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.
f0a0f3dc WCDH: Fix compiler id test for compatibility macros.
627ad96b Project: Detect other compilers before detecting Clang.
bc950169 WCDH: Remove noise from generated defines.
eecd93fc Features: Escape the COMPILE_OPTIONS for dialects.
cb67509b VS: Remove unused parameter of WriteTargetConfigurations
790e1677 VS: Fix subproject .sln dependencies on custom targets
5fba44cf VS: Move VS-only API out of cmGlobalGenerator
It may happen that CMake include is an explicit dependency for some command,
while all CMake includes are set phony in WriteTargetRebuildManifest, this may
lead to duplicate phony generate rules which causes ninja warnings.
We need to remove implicit CMake includes in WriteUnknownExplicitDependencies.
This fixes FindCUDA ninja warnings.
For testing purposes CMake creates dummy memory checkers. The dummy checkers
are in the CMake build tree. Before this change when the path contained the
string valgrind, such as CMake-valgrind, all the checkers were thought to
be valgrind, and this caused tests to fail.
Instead printing complete help cmake/ccmake now prints only Usage section and
extra information how to get more help or start your build.
Implementation Details:
Usage help type was renamed to Help, and new Usage was introduces that prints
only command line usage information without any extra details.
Commands add some extra information when no arguments are passed.
e17a69bc cmDefinitions: Use a hashmap for faster checks
3b21705d cmDefinitions: Avoid a find-then-insert when setting variables
5abfde6c cmDefinitions: Don't store parent lookups
Since commit v2.8.12~300^2~1 (CLI: Suppress the unused warning if the
key value pair is cached, 2013-05-16), cmake::SetCacheArgs saves a
cachedValue pointer and may cause the memory to be freed (by setting the
cache entry) before reading it again. Fix this by saving the old value
in a separate string.
Each project listed in a .sln must be marked (or not) as part of the
"default build" for each configuration. For targets created by the
add_custom_target() command we add them to the default build if they
are not excluded in some way or if another target depends on them.
In the top-level .sln, a custom target is excluded if it is not
created with the ALL option to add_custom_target. In subdirectory
.sln files, a target may also be excluded if it is not within the
directory and is brought into the solution only due to a dependency
from another target in the solution.
Fix the "IsPartOfDefaultBuild" and "IsDependedOn" methods to check
every target to be included in the .sln for a dependency on the
custom target. Otherwise transitive dependencies through targets
not in the current subdirectory will not be considered.
Extend the SubProject test with a custom target to cover this case.
Reported-by: William Deurwaarder <William.Deurwaarder@tomtom.com>
Reported-by: Dirk Steenpass <dirk.steenpass@gmail.com>
Add the ability to parse the XML output of the Jacoco tool.
Jacoco (www.eclemma.org/jacoco) is a Java coverage tool.
Add and integrate a class for the parser and
include a test which utilizes the new parser.
Changing all categories with LC_ALL causes test failures in some locales.
For example, in some locales, the decimal characer could be a comma instead of period.
Factor a WriteMSToolConfigurationValues helper method out of the
cmVisualStudio10TargetGenerator::WriteProjectConfigurationValues method
to isolate the configuration settings specific to MS tools.
The cmVisualStudio10TargetGenerator::ComputeClOptions method is
only called when the target type compiles, so do not duplicate
that check in the implementation.
When a binary output file is to have no extension, the TargetExt
element in the vcxproj cannot be left empty because VS will choose
a default extension. Instead use "." because the Windows filesystem
will treat that as an empty extension.
In cmVisualStudio10TargetGenerator, convert the static functions
currently used to lookup the flag table for each tool into class
methods. This avoids passing the this->LocalGenerator member and
gives the methods access to other information that may be useful
in the future.
86be733f cmGeneratorExpression: Add workaround for Borland compiler
3495ab0a tests: update unused variable test expected output
2a1b2d84 backtrace: Convert to local paths in IssueMessage
a0829205 genex: remove the need for backtraces
efc20569 cmake: remove dummy backtraces for IssueMessage
d46c650d cmMakefile: return a backtrace
Create a Platform/Android module that includes Platform/Linux since
Android is based on Linux. Provide only the minimal settings needed to
get builds with Android NDK toolchains to work.
Disable use of RPATH since the Android loader ignores it and we cannot
predict the install destination anyway.
Android supports soname but shared library names must end in ".so" and
we cannot represent the versioned names with associated symlinks on all
host operating systems anyway. However, we do want the SONAME of
library files to be set so that linking to them by path to the library
file produces NEEDED entries with the soname and not the path. Add a
new CMAKE_PLATFORM_NO_VERSIONED_SONAME setting to tell the
cmTarget::GetLibraryNames method that not to use the VERSION or
SOVERSION target properties in the soname.
In commit 84fdc992 (stringapi: Pass configuration names as strings,
2014-02-09) a few code paths for the Xcode 1.5 single-configuration
generator were not updated to use an empty configuration name instead of
a NULL pointer when no configuration is specified in CMAKE_BUILD_TYPE.
Fix them now.
Some compilers do not offer an option to specify the path to the object
file, but rather only to the directory in which to place the object
file. See issue 14876 for some examples. Add a new OBJECT_FILE_DIR
placeholder to specify the directory containing the object file for the
current compilation. This may differ from the main target OBJECT_DIR
when the object corresponds to a source in a subdirectory.
Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake
file has been configured and loaded during the first project() or
enable_language() command. This gives the toolchain file named by
CMAKE_TOOLCHAIN_FILE a chance to set CMAKE_GENERATOR_TOOLSET. This
point is still early enough to set the generator toolset prior to
the initialization of any languages that might use the toolset.
The cmake::GeneratorToolset member variable remains an indication
of what was specified by the -T option or loaded from the cache.
It does not need to be updated based on the toolchain file setting.
The cmMakefile::TryCompile can still pass cmake::GeneratorToolset
into the inner instance because the try-compiled project will do
platform and language initialization using the CMakeSystem module
configured for the outer project.
Extend the RunCMake.GeneratorToolset test with cases that use a
toolchain file to set CMAKE_GENERATOR_TOOLSET.
Divide the cmGlobalVisualStudio10Generator "PlatformToolset" member into
two members representing the generator-selected default toolset and the
user-specified CMAKE_GENERATOR_TOOLSET value. Prefer the user-specified
value, if any, and then fall back to the generator-selected default.
Add support for Cobertura coverage files written by Java.
Add a test which uses the report from a Java run of Cobertura to calculate coverage.
In the documentation of CTEST_COVERAGE_COMMAND, give a sample .sh file to merge
the Cobertura .ser files and generate the XML report from the merged file.
The coverage.py tool writes out an XML that conforms to the Cobertura
Coverage tool standard. Rename the cmParsePythonCoverage files to
instead be cmParseCoberturaCoverage.
If we fail to create the generator named by CMAKE_GENERATOR, exit
with an error message instead of crashing. While at it, fix the
wording of the error message when CMAKE_GENERATOR is not set.
Extend the RunCMake.CommandLine test with cases covering the
"cmake --build" option when the named directory does not provide
a CMakeCache.txt with a valid CMAKE_GENERATOR.
The VS 7-9 IDEs parse .vcproj file boolean values in lower or upper
case. The .NET XML parsing chokes on anything but "true", "false", "0",
"1". Teach our generators to use lower-case names since they will work
for both parsers. Our VS >= 10 flag tables already use lower-case.
While tracing dependencies of a target, cmTargetTraceDependencies
follows sources by full path to determine if the source is to be
produced by a custom command. Commit 4959f341 (cmSourceFileLocation:
Collapse full path for directory comparisons., 2014-03-27) changed
the storage of target sources to be in the form of a normalized
path instead of an unnormalized path.
The path is followed by looking it up in a mapping via
cmMakefile::GetSourceFileWithOutput to acquire an appropriate
cmSourceFile. The mapping is populated with the OUTPUT components
of add_custom_command invocations, however it is populated with
unnormalized paths. This means that the tracing logic does not
find appropriate cmSourceFiles, and does not generate appropriate
build rules for the generated sources.
Normalize the paths in the OUTPUT components of add_custom_command
to resolve this.
The paths in the DEPENDS component of add_custom_command are also
not normalized, leading to the same problem again. Normalize the
depends paths after generator evaluation and expansion.
Teach set_property and get_property an "INSTALL" property type to be
associated with install-tree file paths. Make the properties available
to CPack for use during packaging. Add a "prop_inst" Sphinx domain
object type for documentation of such properties.
If the coverage.py source file is not found in the source directory, the
build directory is first searched before raising an error.
This is necessary because it is a valid workflow to build a Python
package from source, then install this package to a virtualenv that
lives in the build directory. Tests will run against this deployed
package and therefore the covered source files will be found in a
subdirectory of the build directory, and not anywhere in the source
directory.
Since commit bef93dc5 (Couple of changes: cache variables now have a map
of properties, 2002-09-11) the cmCacheManager::AddCacheDefinition method
accesses its map entry by reference. However, the commit left the
original entry assignment at the end of the method. With Apple Clang
5.1 and libc++ this self-assignment destroys the cache entry property
map.
Drop the self assignment. Also drop the condition around the call to
UnwatchUnusedCli since it was a self-comparison that must always have
been true.
Teach cmake::HandleDeleteCacheVariables to tolerate a missing HELPSTRING
(NULL pointer) when saving cache entries. In the absence of other bugs
this should not be possible, but avoid the crash just in case.
When CMP0053 is in WARN mode, variables get expanded twice, leaking the
fact that the string was expanded twice and changing behavior. Instead,
suppress variable watches when running the expansion to trigger the
CMP0053 warning.
The ALLOWED_UNKNOWN_VARIABLE_READ_ACCESS access type was switched on an
undocumented variable and its lookup caused an unnecessary performance
impact. Remove it.
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.
d1035bd5 cmTarget: Avoid copying container we don't need to copy.
96eb97f8 Help: Fix whitespace in doc link.
0dffbb93 Features: Ensure that list exists to remove from.
When we kill a child we send SIGSTOP first so that we can traverse its
child processes recursively. On unwinding the recursion we then send
SIGKILL. Current Cygwin has trouble when both signals are sent in quick
succession by the parent process. Add a usleep(1) after sending the
first signal to give up our time slice and give Cygwin a chance to
process the first signal before sending the second.
31b3bbd7 Merge branch 'backport-fix-CMP0022-language-propagation' into fix-CMP0022-language-propagation
40b9cd0f CMP0022: Fix link language propagation in NEW behavior
42bbf130 CMP0022: Fix link language propagation in NEW behavior
The languages used in compiling STATIC libraries need to be propagated
to dependents regardless of the settings of INTERFACE_LINK_LIBRARIES or
CMP0022. They are independent of the libraries in the link interface.
Prior to commit v2.8.12~192^2~2 (Introduce the INTERFACE_LINK_LIBRARIES
property, 2013-06-04) the cmTarget::ComputeLinkInterface code path for
"explicitLibraries" could never be taken for STATIC libraries, so the
logic to propagate languages existed only in the non-explicitLibraries
code path. After that commit, INTERFACE_LINK_LIBRARIES could be set for
STATIC libraries to cause the "explicitLibraries" code path to be taken.
The commit also left the old non-explicitLibraries code path conditional
on CMP0022 not being set to NEW. Thus link language propagation was
left missing from two cases by that commit.
The explicitLibraries code path was fixed to propagate languages by
commit v2.8.12~149^2~1 (cmTarget: Fix iface libraries and languages for
static libraries, 2013-07-26). However, the non-explicitLibraries case
was never taught to propagate languages when CMP0022 is set to NEW. Fix
that now. Factor the logic to propagate link languages out of the link
interface libraries conditions so that it always occurs. Update
Tests/Fortran to set CMP0022 to NEW to test this case (because the test
passes only if link language propagation works).
The languages used in compiling STATIC libraries need to be propagated
to dependents regardless of the settings of INTERFACE_LINK_LIBRARIES or
CMP0022. They are independent of the libraries in the link interface.
Prior to commit v2.8.12~192^2~2 (Introduce the INTERFACE_LINK_LIBRARIES
property, 2013-06-04) the cmTarget::ComputeLinkInterface code path for
"explicitLibraries" could never be taken for STATIC libraries, so the
logic to propagate languages existed only in the non-explicitLibraries
code path. After that commit, INTERFACE_LINK_LIBRARIES could be set for
STATIC libraries to cause the "explicitLibraries" code path to be taken.
The commit also left the old non-explicitLibraries code path conditional
on CMP0022 not being set to NEW. Thus link language propagation was
left missing from two cases by that commit.
The explicitLibraries code path was fixed to propagate languages by
commit v2.8.12~149^2~1 (cmTarget: Fix iface libraries and languages for
static libraries, 2013-07-26). However, the non-explicitLibraries case
was never taught to propagate languages when CMP0022 is set to NEW. Fix
that now. Factor the logic to propagate link languages out of the link
interface libraries conditions so that it always occurs. Update
Tests/Fortran to set CMP0022 to NEW to test this case (because the test
passes only if link language propagation works).
Fix the MUMPS coverage parser:
* Account for tabs after entry points
* Stop double incrementing lines that have explicit calls to the 0 line
* If a line has been previously marked as non executable, but then
contains a count, increment it an extra one to push it back into
the executable code set.
Add a custom routine and corresponding coverage files in the test case.
This file is smaller and has cmcov/mcov files that have data for only
that routine.
Add source file properties to control Xcode file type attributes:
XCODE_EXPLICIT_FILE_TYPE => explicitFileType
XCODE_LAST_KNOWN_FILE_TYPE => lastKnownFileType
Add a RunCMake.XcodeProject test to verify generated project content.
Choose the attribute name and file type and send them through a single
attribute generation code path. Compute the file extension only when
needed. Leave the file type selection logic indented in a block so it
can be made conditional later.
Output sent through these APIs is logically part of the CMake process
output. Capture it with callbacks and display it in the cmake-gui
output window along with other messages.
Factor a common callback type out of StdoutCallback. Add an equivalent
StderrCallback. While at it, use "size_t" for the data length instead
of "int".
Teach "ctest --build-and-test" to capture the Stderr callback because
output sent through it is part of the logical CMake process output.
Add properties and variables corresponding to CXX equivalents.
Add features for c_function_prototypes (C90), c_restrict (C99),
c_variadic_macros (C99) and c_static_assert (C11). This feature
set can be extended later.
Add a <PREFIX>_RESTRICT symbol define to WriteCompilerDetectionHeader
to conditionally represent the c_restrict feature.
Add ERROR_SHARING_VIOLATION to the set of errors (previously including
only ERROR_ACCESS_DENIED) that cause a rename (MoveFile) on Windows to
retry. The condition was observed when two renames to the same target
file name were happening simultaneously.
ba387cb8 Help: Add notes for topic 'package-disable-registry'
be8ae960 Allow the Package Registry to be disabled (#14849)
d09fda5d Tests: Improve FindPackageTest for in-source builds
ac24a1c0 Tests: Improve FindPackageTest exported package version
When a project is packaged for redistribution the local package
registries should not be updated or consulted. They are for developers.
Add variables to disable use of package registries globally:
* CMAKE_EXPORT_NO_PACKAGE_REGISTRY that disables the export(PACKAGE)
command
* CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY that disables the User Package
Registry in all the find_package calls.
* CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY that disables the
System Package Registry in all the find_package calls.
Update documentation and unit tests.
bc9a8bba Makefile: Undef FEATURE_STRING iteration define after use.
eb638c75 Tests: Make CompileFeatures feature list lang-specific.
e2f09aff CMakeConfigurableFile: Remove excess newline.
5109b042 Features: Fix GNU 4.8.1 version test.
6a9fdbeb Test: Parameterize the language in the CompileFeature test.
f5bf9d43 Tests: Make CompileFeature tests use highest standard known.
Since commit v3.0.0-rc1~305^2 (Ninja: deptype msvc for Intel's compiler
on Windows, 2013-11-25) we used "deps = msvc" for the Intel compiler.
This is correct only on Windows. On Linux we still want "deps = gcc".
Fix the logic to use "deps = msvc" when the compiler id or the "simulate
id" is "MSVC". This will preserve the behavior on Intel for Windows and
fix the behavior on Intel for Linux. In the future this should be
converted to a platform information module variable.
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.
This policy should be checked at the call site that tries to access the
LOCATION 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 test with a cross-directory case.
Brad King
Kitware Robot
Clinton Stimpson
Ben Boeckel
Ben Boeckel
Bill Hoffman
Martin Mitas
Tim Blechmann
Stephen Kelly
Adam Strzelecki
Joseph Snyder
Nils Gladitz
Mark Salisbury
Zach Mullen
Roni Choudhury
Eric Berge
Daniele E. Domenichelli