We do not add default warning flags on other compilers, and having
a warning flag in the default flags makes it hard for projects to
customize the warning level. They need to use string processing
to remove `/W3` from `CMAKE_{C,CXX}_FLAGS`. Therefore we should
drop it.
However, projects may be using string processing to replace `/W3`
with another flag, so we cannot simply drop it. Add a policy to
drop it in a compatible way.
Fixes: #18317
Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names. We've long hesitated to do this because the idea of "runtime
library selection" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flags requires a policy because existing
projects may rely on string processing to edit them and choose a runtime
library under the old behavior. Add policy CMP0091 to provide
compatibility.
Fixes: #19108
This was forgotten in commit 626c51f47b (VS: Update for Visual Studio
2019 Preview 2, 2019-01-24, v3.14.0-rc1~74^2) when the toolset was
first renumbered to `v142`.
Issue: #19125
-- Rename platform script so it runs before initial try_compile() in
project() command.
-- Fix incorrect variable name GHS_OS_DIR_OPTION
-- Remove unnecessary ".*" from REGEX expression for GHS_CANDIDATE_OS_DIRS
-- Forward GHS_OS_DIR_OPTION to try_compile() and preserve trailing
whitespace of the variable.
Since commit 11da882a12 (Apple: Introduce separate system name for iOS,
tvOS, and watchOS, 2018-01-15, v3.14.0-rc1~14^2~1) we support setting
`CMAKE_SYSTEM_NAME` to `iOS`. Existing iOS toolchain files already
set `IOS` as a short-hand variable, so do the same here.
e53a968ed5 MSVC: Use -D instead of /D in RC_FLAGS
1a281a1acd RC: Pass output file in a way that llvm-rc 7 and below understand
fa339ced67 CMakeVersion.rc: Avoid preprocessor definitions to support llvm-rc
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3007
CrayPrgEnv:
- add a new function __cmake_craype_linktype() that determines what
link mode the Cray compiler wrapper will use in a more sophisticated
way than just MATCHing for static/dynamic on the command line.
- add a new function __cmake_craype_setupenv() that does a
once-per-cmake-run setup that does the following:
1. does a basic check of the wrapper's configuration. Running
cmake and then changing module and/or linktype configuration
may cause build problems (since the data in the cmake cache
may no longer be correct after the change). We look for this
and warn the user about it.
2. uses the "module" provided PKG_CONFIG_PATH environment variable
to add additional prefixes to the system prefix path. This
function used to be done by CrayLinuxEnvironment using the
compiler implicit include/link paths but that is intended
only for cross-compiling on Cray front-end nodes. Since
CrayPrgEnv runs on both front-end and compute nodes, we
migrate this function here.
CrayLinuxEnvironment:
- No need to set variables like CMAKE_SHARED_LIBRARY_PREFIX to values
that have already been properly established by CMakeGenericSystem.cmake.
Remove redundant sets of CMAKE_SHARED_LIBRARY_PREFIX,
CMAKE_SHARED_LIBRARY_SUFFIX, CMAKE_STATIC_LIBRARY_PREFIX,
CMAKE_STATIC_LIBRARY_SUFFIX, CMAKE_FIND_LIBRARY_PREFIXES, and
CMAKE_DL_LIBS.
- No need to add $ENV{SYSROOT_DIR}/usr/include to CMAKE_SYSTEM_INCLUDE_PATH
when we already added $ENV{SYSROOT_DIR}/usr to CMAKE_SYSTEM_PREFIX_PATH.
- Remove __cray_list_intersect(), __list_clean_dupes(), and buggy
code that adds compiler implicit includes/libs to
CMAKE_SYSTEM_INCLUDE_PATH and CMAKE_SYSTEM_LIBRARY_PATH. This
function has migrated to CrayPrgEnv.cmake, as noted above.
See discussion in issue #17413 for additional details.
Since commit 7cd65c97fa (Add CMAKE_SYSROOT variable to set --sysroot
when cross compiling., 2013-04-13, v3.0.0-rc1~342^2) we have prefixed
the value of `CMAKE_SYSROOT` to implicit include directories. This was
done because we hard-coded `/usr/include` as an implicit include
directory without accounting for the sysroot. Instead we should prefix
the hard-coded paths when they are constructed. Update the
`Platform/UnixPaths` module to do this as `Platform/Darwin` already
does.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2) the values of the
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` variables are computed from
a real compiler invocation so they already account for the sysroot
prefix. In commit 6fc3382944 (Update logic for sysroot in detected
implicit include directories, 2019-02-13, v3.14.0-rc2~6^2) we attempted
to apply the prefix conditionally, but that is incorrect because the
compiler's real implicit include directories are not all under the
sysroot. Instead assume that all implicit include directories in
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` already have the sysroot
prefix if needed. Code that constructs the value must be responsible
for that because it is the only place that knows.
The change in commit 15ad830062 (Refactor exclusion of -I/usr/include to
avoid per-language values, 2019-01-21, v3.14.0-rc1~108^2~4) caused the
exclusion to apply to Fortran, but it was only meant for C, CXX, and
CUDA. The purpose of the change was to prepare for the value of
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` to be computed from the
actual compiler instead of hard-coded. We need to preserve exclusion of
`-I/usr/include` if the compiler has any implicit include directory that
looks intended to replace it, e.g. `<sdk>/usr/include` on macOS.
Fixes: #18914
In commit 1293ed8507 (ParseImplicitIncludeInfo: keep implicit incl.
consistent when rerunning cmake, 2019-01-30, v3.14.0-rc1~26^2) the
`Platform/UnixPaths` module was updated to add `/usr/include` to
`CMAKE_{C,CXX,CUDA}_IMPLICIT_INCLUDE_DIRECTORIES` through an
initialization variable used by `CMakeDetermineCompilerABI` instead of
directly. This approach makes it only a default that can be overridden
by detection of the implicit include directories really used by the
compiler.
The addition of `<sdk>/usr/include` to default implicit include
directories by the `Platform/Darwin` module needs the same update but
was accidentally left out of the original commit.
e8ee8cab97 Xcode: Completely disable code signing for compiler id detection
11da882a12 Apple: Introduce separate system name for iOS, tvOS, and watchOS
36cf44a7a3 Tests: Isolate RunCMake.XcodeProject per-device cases from host arch
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2392
- Remove code signing requirements for non-macOS
- Do not set deployment target for non-macOS
- Build static library for compiler feature detection for non-macOS
- Use framework to run CompilerId tests for watchOS
- Port tests to new SDK handling
- Add new Apple cross-compiling section to toolchain documentation
Closes: #17870
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
The first time you run cmake, it sets the implicit include path
to the value reported by the parser (and this value gets saved
in CMake${lang}Compiler.cmake). But if you re-run cmake,
UnixPaths.cmake blindly appends an extra /usr/include to the
value saved in CMake${lang}Compiler.cmake. That should not be
harmful in most cases, but we want later runs of cmake to be
consistent with the initial one. Resolve using a solution
suggested by Brad King:
- UnixPaths now sets the default implicit include path in a new
variable named _CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES_INIT
This value is only used the first time cmake is run (by
CMakeDetermineCompilerABI.cmake when it calls the implicit
include parser).
- if CMakeDetermineCompilerABI.cmake successfully calls the
implicit include parser, it overwrites the value in
_CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES_INIT with the
value returned by the parser
- CMakeDetermineCompilerABI.cmake always sets
CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES to the above value
of _CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES_INIT
- the final value of CMAKE_${lang}_IMPLICIT_INCLUDE_DIRECTORIES gets
saved to CMake${lang}Compiler.cmake when it is regenerated after
the compiler tests are done.
- CMakeDetermineCompilerABI.cmake is only executed the first time cmake
is run. Additional runs of cmake directly load the implicit include
path from the value saved in CMake${lang}Compiler.cmake (the parser
and _INIT variable are not used).
The above depends on UnixPaths.cmake being loaded to set the _INIT value
before CMakeDetermineCompilerABI.cmake runs the implicit include parser.
Add a `CMAKE_PLATFORM_IMPLICIT_INCLUDE_DIRECTORIES` to contain the
hard-coded list of paths to be excluded from `-I` arguments so that the
values remain excluded even if the per-language
`CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES` variants change.
This is needed to preserve our historical exclusion of `-I/usr/include`
even when it is not a real implicit include directory. A policy may be
needed to remove it later.
-- standalone platforms will not build if bsp/os is specified in project file
-- integrity platforms will always print these directives because they are required
-- cleanup -os_dir setting
allow customization of the actual setting because it is determined by tool-set customization files
remove variable that was set but never used
-- add message when using default values
bd9bfc6449 MSVC: Respect CMAKE_RC_COMPILER and CMAKE_MT in vs_link_{dll,exe}
0033676796 CUDA: Enable RC language on Windows
02f566a559 MSVC: Factor out enable_language(RC) call into helper macro
b601bb6f1c CUDA: Find CMAKE_LINKER on Windows
3eebe28ef4 cmLocalNinjaGenerator: Simplify CreateRulePlaceholderExpander
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2424
CMake commands vs_link_dll and vs_link_exe, performing linking on MSVC,
are responsible for calling resource compiler and manifest tool.
Before this commit, both of these tools were called directly, with the
expectation that they are available in the `PATH`. This has been fixed
by respecting CMake variables `CMAKE_RC_COMPILER` and `CMAKE_MT`
defining paths to these tools.
Fixes: #17804
All of NetBSD, FreeBSD, OpenBSD and DragonFly BSD support `$ORIGIN`,
but the last two require `-z origin` as documented at
https://lekensteyn.nl/rpath.html
The `-z origin` option causes a flag bit to be set and has no effect if
the `RPATH` does not contain expandable tokens.
This makes binaries independent of the build directory by not embedding
the build directory via RPATH. The tests are partially based on the
existing RuntimePath test, but with the check moved into a POST_BUILD
command such that it can be skipped when the platform lacks support.
Fixes: #18413
When we set `CMAKE_<LANG>_COMPILER_TARGET` to the Android target
architecture, add it to `CMAKE_<LANG>_COMPILER_PREDEFINES_COMMAND` also.
This is needed to make moc predefines aware of `__ANDROID__`.
Fixes: #18425
NDK r18 drops GCC toolchains and some STL types. We need to choose a
clang toolchain by default when no gcc toolchains are available. Switch
the STL type default to `c++_static` when the old `gnustl_static`
default is not available.
Update the test suite to not run tests for STL types that do not exist.
Also do not expect the gcc toolchain `cpp` tool to be available because
r18 does not provide it. Also teach it to tolerate `gcc -dumpmachine`
output like `arm--linux-android` that differs from the toolchain prefix.
Fixes: #18301
Use `curand_static` to identify directories containing device libraries
because `cublas_device` is deprecated and will be removed in the future.
Issue: #18290
-- Update how the latest OS is determined; scan the location GHS_OS_ROOT and sort it
No longer use registry settings looking for installations
The registry values are assigned in installation order for Green Hills tools not version order
Filter out files from the list of directories (i.e if int1234.zip and int1234 are both in root folder)
Just like the existing WindowsPhone and WindowsStore platform modules
for MSVC, just include the corresponding Windows platform modules.
MinGW tools (both with GCC and Clang) can be used for building for
Windows Store, even though it isn't a very common or simple setup.
