The Custom-Symbolic-and-Byproduct case fails strangely on some
filesystems used by our nightly testing. Somehow on the first build the
`use-byproduct` output ends up with a timestamp older than
`gen-byproduct-stamp` even though the build log clearly shows them build
in the correct order (and must according to build system dependencies).
Work around this problem by adding an extra delay before building
`use-byproduct`.
Tested-by: Gerhard Grimm <gerhard.grimm@detec.com>
The change in commit v3.5.0-rc1~198^2 (Ninja: Always re-run custom
commands that have symbolic dependencies, 2015-11-19) broke the
byproducts feature added by commit v3.2.0-rc1~340^2~2 (Add an option for
explicit BYPRODUCTS of custom commands, 2014-11-13) when SYMBOLIC
outputs also appear. This case occurs with AUTORCC-generated custom
targets because the output is SYMBOLIC (to always run) and the generated
file is a byproduct (for restat so dependents do not run unnecessarily).
The two use cases conflict because Ninja does not support per-output
restat. Favor restat whenever byproducts are present because it is
required for byproducts to work correctly. In use cases where we want
an always-run chain we simply will not be able to also use byproducts.
Fix logic introduced by commit v3.5.0-rc1~198^2 (Ninja: Always re-run
custom commands that have symbolic dependencies, 2015-11-19) to not
consider only the last output. We need to know if any output is
SYMBOLIC, so stop checking as soon as one is found.
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.
Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly. Fix the
separate compilation code path to not add its own quoting when the
VERBATIM option will be used.
The fix in commit v3.5.0-rc1~27^2 (FindPkgConfig: set standard variables
in the cache, 2016-01-20) added the wrong variable name to the cache.
The test was only testing that the cache variable existed, not that it
also had the correct value. Update the test to ensure that the cache
value matches the local variable value.
Reported-by: Bernd Lörwald
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.
If list of valid target architectures is empty for given SDK then there will
be no VALID_ARCHS build setting returned by Xcode. Return "" (empty string)
explicitly in this case. This may happens if CMAKE_IOS_INSTALL_COMBINED is ON
but only one architecture used in target.
Depending upon the configuration, certain components may or may not
be installed, for example Boost.Regex, but other components may
still have header dependencies upon these components which will
obviously fail to work. Since we can't make a sensible
determination with the hardcoded dependency information, we
choose to interpret these dependencies less strictly.
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>
Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly. However,
this breaks the special `$(VCInstallDir)` placeholder used with Visual
Studio generators. Since we do not support preservation of such
placeholders with VERBATIM (see issue #15001) we must fall back to not
using VERBATIM when the placeholder is used.
A better fix would be to stop using `$(VCInstallDir)` and use the value
of `CMAKE_${CUDA_C_OR_CXX}_COMPILER` instead, but that will require
additional semantic and documentation changes. For now simply fix the
regression with the above approach.
Reported-by: Stephen Sorley <Stephen.Sorley@jhuapl.edu>
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 option does not actually participate in argument groups like the
others because it does not actually install anything. Fix the order
in the documentation accordingly.
Reported-by: Daniel Wirtz <daniel.wirtz@simtech.uni-stuttgart.de>
We deprecated this module in commit v3.5.0-rc1~295^2
(CMakeForceCompiler: Deprecate this module and its macros, 2015-10-19)
in order to determine whether anyone still has use cases that require
it. Indeed we still need to provide a way to work with toolchains that
cannot link binaries without special flags. Remove the deprecation
warnings until we can provide an alternative to the module for this use
case.
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.
The fix in commit v3.5.0-rc1~84^2 (Xcode: Escape all backslashes in
strings, 2015-12-27) is a change in behavior that can break existing
projects that worked around the inconsistency with other generators.
Add a release note to call attention to this change in behavior.
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.
Use a custom action to look for Uninstall.exe in the user
selected installation prefix.
Its presence indicates a previous NSIS installation.
Inform the user and request manual resolution of the issue.
Brad King
Yves Frederix
Ben Boeckel
Sean McBride
Ruslan Baratov
Roger Leigh
Ashley Whetter
Bartosz Kosiorek
Dimitar Yordanov
Nils Gladitz