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.
Brad King
Kitware Robot
Ben Boeckel
Martin Mitas
Tim Blechmann
Bill Hoffman
Ben Boeckel
Clinton Stimpson
Stephen Kelly
Adam Strzelecki