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.
Fix the DebuggerTool RemoteExecutable value added by commit a22f9967
(VS: Optionally generate remote directory for WinCE projects,
2016-02-15) to account for the configuration when computing the target
name.
Use cmSystemTools::GetCMakeRoot() which always knows the location of our
resources. Do not depend on CMAKE_ROOT because the user could unset it
from the cache.
Teach the VS 2008 and 2005 generators to set the `RemoteDirectory`
in `DeploymentTool` and the `RemoteExecutable` in `DebuggerTool`.
Use a `DEPLOYMENT_REMOTE_DIRECTORY` target property to specify the
value.
491b41dd Help: Add notes for topic 'vs-clang-cl'
ad6d27ac Tests: do not build PrecompiledHeader on Clang/C2
a0f0541f Tests: fix PDBDirectoryAndName on Clang/C2
3541af67 Tests: fix Plugin building on Clang/C2
1902c293 Tests: fix complexOneConfig building on Clang/C2
cab2ec11 Tests: fix Complex building on Clang/C2
ada3736c Tests: fix Module.GenerateExportHeader building on Clang/C2
123b7e13 Tests: fix AliasTarget building on Clang/C2
445d4d4b VS 14: Add flag map for -std= to CppLanguageStandard tag in project files
0a785eb4 Features: Clang has no cxx_decltype_incomplete_return_type in MSVC sim mode
2c2ec488 VS: in Clang/C2 toolset, setup correct compiler settings
37afe00f CMakeDetermineCompilerId: Add detection of clang.exe bundled with VS
Teach the Ninja generator to add the `-current_version` and the
`-compatibility_version` flags based on the VERSION and SOVERSION target
properties just as the Makefile generators do.
Signed-off-by: Bruce Stephens <bruce.r.stephens@gmail.com>
Move this method from cmMakefileLibraryTargetGenerator so it can be
re-used for the Ninja generator too.
Signed-off-by: Bruce Stephens <bruce.r.stephens@gmail.com>
Calling `project()` or `enable_language()` from a toolchain file will
infinitely recurse since those commands load the toolchain file.
Diagnose and reject this case with an error message instead of crashing
when the stack eventually overflows.
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>
When performing some other testing, the globs for Blanket.js and Delphi
code coverage are picking up unintended files. Change the query for the
Delphi coverage to follow the naming convention, and check the second line
of the found JSON files for certain text before parsing them as coverage files.
Although we fail with an error on a hash mismatch, it is not a fatal
error so the script may continue processing. If the download itself had
no error then report in the STATUS variable that the operation was not
successful due to the hash mismatch.
Suggested-by: Tobias Hieta <tobias@hieta.se>
With this patch, the builtin macros and include dirs are only
added to the project file if the C/CXX langauges are really enabled.
I.e. before this patch the CXX-stuff was in the project file as soon
as CXX had been enabled at least once for this build tree.
I.e. disabling CXX later on did not remove the CXX macros etc.
from the project file (related to #15150)
Alex
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>
This is done the same way as for Eclipse: cmake tries to determine
the number of CPUs, and then adds the respective -jN to the make
invocations in the project file.
Alex
Create a `CMAKE_TRY_COMPILE_TARGET_TYPE` option to specify use
of `add_library(... STATIC ...)` for the generated test project.
This will be useful for cross-compiling toolchains that cannot
link a binary without custom flags or scripts.
This reverts commit 9beb2744d7.
Our AUTOMOC documentation states that it should be possible to
`#include "moc_foo.cpp"` in `foo.cpp`, and this will not work if
the file is placed in a different directory. Another solution
will need to be found to the original problem.
Reported-by: Stephen Kelly <steveire@gmail.com>
The new `%s` format specifier is substituted by file()/string()
`TIMESTAMP` sub-commands with the number of seconds since unix-epoch
(1970-01-01 00:00:00 UTC).
Co-Author: Nils Gladitz <nilsgladitz@gmail.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>
More elaborate selection of the `compiler` tag in the generated
CodeBlocks project file:
* Fortran language support
* support for several of the predefined compilers recognized by
CodeBlocks (16.01)
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.
We represent target dependency sets as `set<cmTargetDepend>` which
orders by a `cmGeneratorTarget const*` pointer value. Therefore the
order of dependencies encountered in AppendTargetDepends is not
predictable. Sort them by content to make the result deterministic.
Generate custom command build statements in the order we encounter
source files specifying them. Do not depend on pointer values of
internally allocated structures for ordering.
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.
a1ad098d Tests: Avoid OS X 10.5 limitation warning in RunCMake.install test
47460f3e install(EXPORT): Fix crash on target in another directory
e86383e1 Tests: Use newer policy settings in RunCMake.install test
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>
Previously we did not clearly document that `--target` is only supported
to be specified once. Even worse, specifying it multiple times would
silently ignore any previously specified targets and only build the last
target.
Update the documentation to specify this. Update the implementation to
reject multiple `--target` options to prevent user errors.
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>
Let us take an example of a project that has some tests in a component
that need to be installed into a dedicated test package. The user
expectation is that the result could be achieved by typing the
following:
make
make tests
make install
DESTDIR=/testpkgs make install-tests
However this results in test components in the default installation as
well as the testpkg.
Add an EXCLUDE_FROM_ALL option to the install() command to tell it that
the installation rule should not be included unless its component is
explicitly specified for installation.
Brad King
Kitware Robot
Sean McBride
Andrej Bosik
Mariusz Pluciński
Gregor Jasny
Bruce Stephens
Fabian Otto
Joseph Snyder
Alex Neundorf
Robert Goulet
Cristian Rodríguez
Jose-Luis Blanco-Claraco
Daniel Wirtz
Melven Roehrig-Zoellner
Dimitar Yordanov
Tobias Hunger
Sebastian Schuberth
Christoph Grüninger
Nick Lewis
Ashley Whetter