Rename methods:
* `cmMakefile::Find{ => LocalNonAlias}Target`
* `cmLocalGenerator::Find{ => LocalNonAlias}GeneratorTarget`
These names clarify that they are for directory-local target names
and do not consider alias targets.
Refactoring in commit v3.5.0-rc1~272^2~11 (cmTarget: Implement ALIAS in
terms of name mapping, 2015-10-25) accidentally introduced logic that
assumes ALIAS targets always reference targets in their own directory.
Fix this and add a test case.
The configure-step fix is that `cmMakefile::FindTarget` should not consider
aliases. The purpose of this method is just to look up targets local to
a directory. Since ALIAS and normal targets share a namespace we know a
locally defined target will never collide with an ALIAS target anyway.
The method has 3 call sites, and this change is safe for all of them:
* `cmInstallCommand::HandleTargetsMode`: Rejects aliases before the call.
* `cmFLTKWrapUICommand::FinalPass`: Should never have considered aliases.
* `cmMakefile::FindTargetToUse`: Falls back to a global lookup anyway.
The generate-step fix is that `cmLocalGenerator::FindGeneratorTarget`
should not consider aliases. This method is the generate-step
equivalent to the above. The method has 2 call sites, and this change
is safe for both of them:
* `cmInstallTargetGenerator::Compute`: Never uses an alias target name.
* `cmLocalGenerator::FindGeneratorTargetToUse`: Falls back to global lookup.
Reported-by: Matteo Settenvini <matteo@member.fsf.org>
Re-lookup a variable value when an associated VariableWatch is executed
in cmMakefile::GetDefinition.
This fixes a problem with 'def' sometimes becoming invalid due to memory
reallocation inside an std::vector. In this case, the problem was that
if the call to VariableAccessed actually executed a callback function,
the internal state of the makefile has changed due to the associated
function scope being pushed. This in turn implies that a new
cmDefinitions instance was pushed in cmMakefile::VarTree. As
cmLinkedTree is based on an std::vector, this push can have triggered
reallocation of its internal memory buffer. However, as the value of
'def', which was computed on method entry, actually points to a property
of one of the cmDefinitions instances in cmMakefile::VarTree,
reallocation can invalidate the value of 'def' so that it cannot simply
be returned at the end of the function. The solution implemented here is
to simply lookup the value of 'def' again.
Some compilers on OS X report errors in the CoreServices framework headers.
Check for support of the header ahead of time and compile the relevant code
only when the header is available.
In commit v3.5.0-rc1~232^2 (CPackDMG: Add support for multilingual SLAs,
2015-10-19) we added use of the Carbon framework in order to get access
to its APIs to convert Script Manager RegionCode values. This is not
necessary. Instead we can use CoreServices.
While at it, replace individual CoreFoundation includes with including
the entire framework, which is the correct way.
Since commit v3.4.2~2^2 (VS: Fix VS 2015 .vcxproj file value for
GenerateDebugInformation, 2016-01-08) we generate invalid project
files for the v110 and v120 toolsets. VS complains:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(639,9):
error MSB4030: "Debug" is an invalid value for the "GenerateDebugInformation" parameter of
the "Link" task. The "GenerateDebugInformation" parameter is of type "System.Boolean".
This reveals that our VS flag map selection should be based on the
toolset instead of the version of VS. However, that will be a
non-trivial change so for now fix this particular use case by
hard-coding a correction to the flag map.
Reported-by: Gregor Jasny <gjasny@googlemail.com>
In commit v3.5.0-rc1~43^2 (Fix export of STATIC library PRIVATE
dependencies with CMP0022 NEW, 2016-01-15) we taught
target_link_libraries to generate `$<LINK_ONLY:$<TARGET_NAME:dep>>` in
INTERFACE_LINK_LIBRARIES instead of `$<LINK_ONLY:dep>` so that `dep` can
be recognized as a target name and updated during export. However, this
approach does not work when `dep` is just a plain library name and not a
target because `$<TARGET_NAME:...>` requires the name of a reachable
target.
Since we do not know during target_link_libraries whether the name will
correspond to a reachable target or not, we cannot inject the
`$<TARGET_NAME:...>` expression. Revert this change and solve the
original problem instead by teaching the export logic to recognize and
update target names directly in `$<LINK_ONLY:...>` expressions.
Reported-by: Ben Boeckel <ben.boeckel@kitware.com>
The re-implementation in commit v3.5.0-rc1~116^2~1 (CMakeParseArguments:
replace by native cmake_parse_arguments command, 2015-12-05) introduced
a regression when parsing the ARGN arguments with cmake_parse_arguments.
The original implementation used
foreach(currentArg ${ARGN})
to iterate over input arguments. This flattened ;-lists within the
arguments whether they were quoted or not. Fix our new implementation
to preserve this behavior and add a test case to cover it.
Signed-off-by: Dimitar Yordanov <dimitar.yordanov@sap.com>
Signed-off-by: Matthias Maennich <matthias.maennich@sap.com>
Refactoring in commit v3.3.0-rc1~29^2~1 (cmState: Host some state from
the cmGlobalGenerator, 2015-05-24) moved storage of some generator
traits over to cmState. However, it accidentally removed initialization
of the values from the cmGlobalGenerator constructor. This is needed
because generator subclasses update the settings in their constructors.
Since a single cmState instance is shared across multiple build trees by
cmake-gui, initializing the values in its constructor is not enough.
Fix this by restoring the needed initializations to the
cmGlobalGenerator constructor.
This version introduced CURLE_NOT_BUILT_IN which we have used since
commit v3.4.0-rc1~211^2~4 (cmCurl: Tolerate lack of CURLOPT_CAPATH
support, 2015-08-12). For older versions, just define the name to the
then-unused error code so that we can compile.
In commit v3.5.0-rc1~272^2~6 (cmGlobalGenerator: Add FindGeneratorTarget
API, 2015-10-25) a lookup was implemented via linear search. Replace it
with an efficient data structure.
Suggested-by: Stephen Kelly <steveire@gmail.com>
Refactoring in commit v3.5.0-rc1~272^2~13 (cmGlobalGenerator: Remove
direct storage of targets, 2015-10-25) replaced an efficient data
structure mapping from target name to cmTarget instance with a linear
search. Lookups through cmGlobalGenerator::FindTarget are done a lot.
Restore the efficient mapping structure with a name indicating its
purpose.
Reported-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Refactoring merged by commit v3.5.0-rc1~299 (Merge topic
'use-generator-target', 2015-10-20) in and around
commit v3.5.0-rc1~299^2~13 (cmExportSet: Store a cmGeneratorTarget,
2015-10-17) changed export sets to delay looking up actual targets and
stores only their names. However, in InstallCommand::HandleExportMode
we need to lookup targets immediately to check them for
EXPORT_LINK_INTERFACE_LIBRARIES. The check was accidentally made local
to the current directory, so if an export set contains a target from
another directory the lookup fails and CMake crashes. Fix the check to
look up the target name globally, and tolerate when no target is found
just in case.
Reported-by: Kelly Thompson <kgt@lanl.gov>
Refactoring in commit v3.5.0-rc1~347^2~2 (Set the current dirs on the
snapshot before creating the cmMakefile) accidentally changed the
source and binary directories configured in `cmake -E cmake_depends`
for use during dependency scanning. This can cause the wrong directory
information to be loaded. It also breaks Fortran module dependency
scanning for modules provided by targets in subdirectories that do
not have Fortran_MODULE_DIRECTORY set.
Fix the dependency scanning directory configuration and add a test to
cover the Fortran module case in which the breakage was observed.
Reported-by: Kelly Thompson <kgt@lanl.gov>
While evaluating `if(MATCHES)` we get a `const char*` pointer to the
string to be matched. On code like
if(CMAKE_MATCH_COUNT MATCHES "Y")
the string to be matched may be owned by our own result variables.
We must move the value to our own buffer before clearing them.
Otherwise we risk reading freed storage.
The add_custom_command(TARGET) signature only works for targets defined
in the current directory. Clarify this in the error message when the
target exists but was defined elsewhere.
Inspired-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Brad King
Yves Frederix
Sean McBride
Dimitar Yordanov
Kitware Robot
Christoph Grüninger