a624a3e1b3 Ninja: Use deps=gcc for Intel Compiler on Windows
f4f3b6b9af Ninja: Detect when ninja is new enough to support a multi-line depfile
699cd03212 Ninja: Drop unnecessary deptype customization infrastructure
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2893
be7b30f67e Find{BLAS,LAPACK}: Add note and example for using Intel MKL
b323407235 Find{BLAS,LAPACK}: Update docs to use modern conventions
ba30b94435 FindLAPACK: Remove extra indentation from a line
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2880
Use the `-s ours` merge strategy to avoid conflicts. Our side was
already fixed by commit 8b63265ea5 (FindLAPACK: Unify internal variables
related to MKL, 2018-11-18) as part of other work.
Since commit 192a9182f8 (FindLAPACK: MKL clean up and fix for windows,
2013-10-08, v3.0.0-rc1~538^2), FindLAPACK accidentally used FindBLAS's
`BLAS_` prefix for some of its check results.
Since commit 5b8f69ebe9 (FindBLAS: Detect implicitly linked BLAS
library, 2018-08-28, v3.13.0-rc1~150^2~2), FindBLAS stores a check
result in a plain `BLAS_WORKS` variable. The typo in FindLAPACK happens
to cause a collision with that name.
The typo was already fixed in post-3.13 development as part of other
work in commit 8b63265ea5 (FindLAPACK: Unify internal variables related
to MKL, 2018-11-18). Fix the typo in the 3.13 version of FindLAPACK to
avoid the collision. Otherwise it could cause FindLAPACK to incorrectly
determine that a certain library combination does not work (or
incrrectly that it works).
Fixes: #18860
91d98542d2 Merge branch 'autogen-qt-version-from-dirprops-release' into autogen-qt-version-from-dirprops-master
062d21c36a Autogen: Read the Qt version from directory properties as well
17ac7c4024 Tests: add cases for providing Qt5Core_VERSION manually
2df6d69014 AutoGen: query Qt5 version from directory properties
b598dfb65e Tests: add cases for providing Qt5Core_VERSION manually
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2883
* 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.
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.
KWSys now computes a default `CMAKE_CXX_STANDARD` value if it is
not told what standard to use. When `CMake_NO_CXX_STANDARD` is
enabled, tell KWSys not to do that.
Code extracted from:
https://gitlab.kitware.com/utils/kwsys.git
at commit ce89cada1c48be31e6294a984b15c2c75b66eab0 (master).
Upstream Shortlog
-----------------
Brad King (2):
5d92e8d9 Require CMake 3.1 or higher for KWSys
6db3c607 Require C++11 or higher to compile KWSys
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
