* The `InTryCompile` member has been unused since commit 62854e9966
(cmState: Move try_compile state from cmake class., 2015-04-11,
v3.3.0-rc1~196^2~9).
* The `ConvertMessageType` and `IsMessageTypeVisible` members have been
unused since commit 421012a330 (cmMessenger: Extract from cmake class,
2016-01-28, v3.7.0-rc1~222^2~1).
* The `InitializeProperties` member has been unused since commit
de722d7d63 (Move property initialization to cmState., 2015-04-06,
v3.3.0-rc1~196^2~1).
Co-Author: Vitaly Stakhovsky <vvs31415@gitlab.org>
Ninja 1.9 supports the depfile format generated by this compiler.
Use `deps = gcc` when the version of Ninja is new enough.
Unfortunately the Intel Compiler for Windows does not properly
escape spaces in paths written to a depfile so if there is a
space in the path we must still fall back to `deps = msvc`.
Fixes: #18855
Ninja 1.9 supports the multi-line depfile format generated by the
Intel Compiler for Windows. Teach the global generator to detect
when the version is new enough to support this.
Do not pass `CMAKE_NINJA_DEPTYPE_<LANG>` in place of `deps = gcc`.
If Ninja ever introduces a new dependency type we will likely need
to update CMake for it anyway.
Using `xcodebuild -enableAddressSanitizer YES ...` causes object files
to be placed in a different directory name. Xcode provides a
placeholder for this that we can use in `OTHER_LDFLAGS` to reference
object files for linking the dependents of object libraries. However,
CMake's features for installing and exporting object libraries depend on
knowing the real path with no placeholders. For these cases, use the
default object directory. Users will then have to choose between
sanitizers and the installation and export features, but both will work
individually.
Fixes: #16289
The `CONFIGURATION_BUILD_DIR` value in the Xcode project file specifies
where to place the library artifact. For object libraries we've used
the `Objects-normal` directory to hide away the `.a` that we otherwise
cannot stop Xcode from producing. The parent of this directory is also
specific to the target and does not vary with Xcode's sanitizer
features, so move the artifact there.
Issue: #16289
The `FRAMEWORK` target property affects the way the `install()` command
treats the target and so should be set first. Our implementation
assumed that this was always the case and led to an assertion failure.
Prior to CMake 3.12 this was visible only when using an explicit
`LIBRARY ... NAMELINK_ONLY` option, but commit 0212d7c762 (install: add
NAMELINK_COMPONENT argument, 2018-04-18, v3.12.0-rc1~139^2~3) made
it possible with a simple `LIBRARY DESTINATION`.
Fully supporting out-of-order specification will require non-trivial
refactoring to defer install generator creation to generate time.
For now simply restore the old behavior of installing the framework
to the library destination and warn about the case.
Fixes: #18848
The `FRAMEWORK` target property affects the way the `install()` command
treats the target and so should be set first. Our implementation
assumed that this was always the case and led to an assertion failure.
Prior to CMake 3.12 this was visible only when using an explicit
`LIBRARY ... NAMELINK_ONLY` option, but commit 0212d7c762 (install: add
NAMELINK_COMPONENT argument, 2018-04-18, v3.12.0-rc1~139^2~3) made
it possible with a simple `LIBRARY DESTINATION`.
Fully supporting out-of-order specification will require non-trivial
refactoring to defer install generator creation to generate time.
For now simply restore the old behavior of installing the framework
to the library destination.
Fixes: #18848
VS 2017 and VS 2019 provide `amd64/MSBuild.exe` variants next to
their `MSBuild.exe` tools. When the 64-bit host toolchain is
selected (e.g. via `host=x64`), select the 64-bit MSBuild too.
Fixes: #18219
This will allow `CMAKE_GENERATOR_TOOLSET` to influence build tool
selection.
For reference, commit f8cb9944a1 (Find native build tool after
determining the target system, 2017-09-26, v3.10.0-rc1~31^2) already
delayed this step from where it was historically.
On Apple, the implementation of cmGlobalXCodeGenerator::Open uses
LSOpenCFURLRef from CoreServices. This get's transitively pulled in
from CMake's libuv build but ends up generating a linker error when
using an external libuv. This explicitly adds the appropriate
dependency.
While we already support `VERBOSE` environment variable and
`CMAKE_VERBOSE_MAKEFILE` cached variable, add `-v` and `--verbose`
command line options to be able to activate verbose output directly from
CMake's build tool mode command line.
Also make `msbuild` honor the verbosity setting. `xcodebuild` still
doesn't honor the verbosity setting as it will need a policy added
and reworking of cmGlobalGenerator and cmsys to support
multiple command invocation.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07) we now have compiler implicit include
directory computation for gcc and clang. It should be safe now to pass
these to `moc`. This patch re-enables passing the compiler implicit
include directories to `moc`, which was disabled due to issue #18669.
Fixes: #18041
Issue: #18669
Use a dedicated `std::set` for implicit include directories instead
of (ab)using the emitted variable. This in combination with lambdas
makes it easier to comprehend which paths are emitted.
For the implicit include directories we used to omit the
`CMAKE_SYSROOT_COMPILE`/`CMAKE_SYSROOT` prefix. This has been changed and
the implicit paths are returned prefixed. Implicit include directory returning
is only ever used by QtAutoGen which requires prefixed paths. QtAutoGen passes
the (implicit) include paths to the `moc` which isn't aware of
`CMAKE_SYSROOT_COMPILE`/`CMAKE_SYSROOT`.
Brad King
Kitware Robot
Harry Mallon
Regina Pfeifer
Sebastian Holtermann
Taylor Holberton
Ben Boeckel
Artur Ryt
Vitaly Stakhovsky
Chuck Atkins
Florian Maushart