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.
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>
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.
Stephen Kelly
Brad King
Kitware Robot
Bill Hoffman