Make sure `std::cbegin`, `std::cend`, and `std::size` work in C++17 or
C++14 mode before choosing the corresponding standard level for
compiling CMake itself. This helps in cases that the compiler is using
a standard library too old to support the full standard level chosen.
Make sure `std::cbegin`, `std::cend`, and `std::size` work in C++17 or
C++14 mode before choosing the corresponding standard level for
compiling CMake itself. This helps in cases that the compiler is using
a standard library too old to support the full standard level chosen.
Prior to LLVM 8.0, `llvm-rc` does not recognize `/fo` without a space
after it. Add the space unconditionally because MS `rc` accepts it too.
Issue: #18957
f22c18b1c1 ninja: name dyndep internal files using the object file
7c78adca8e cmNinjaTargetGenerator: remove "preprocessed" mentions in dyndep
933dd91642 ninja: do not assume explicit preprocessing uses that output
2c0a7bc770 ninja: pass language to cmake_ninja_depends
72f9bb2993 ninja: make dyndep generation language aware
2dd0cb7aeb Help: note that Ninja also uses OBJECT_OUTPUTS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2997
e795be115e Merge branch 'master' into cmake_role-vs-fix
4b95e7fe63 CMAKE_ROLE: Fix value in --build for Visual Studio generators
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3028
Since commit e9a1ddc594 (FindThreads: Replace the pthread symbol
checking in libc., 2018-11-18, v3.14.0-rc1~292^2) we check libc for
`pthread_kill` instead of `pthread_create`. However, on FreeBSD
`pthread_kill` is in libc but not `pthread_create`. Discussion in the
original merge request for the above commit also considered
`pthread_key_create`, `pthread_self`, and `pthread_attr_init`. Every
symbol seems to have some reason it is not an appropriate choice.
Revert to the pre-3.14 behavior of using `pthread_create` pending
further investigation.
On Linux containers (tested with LXC and Docker) getconf returns the
host CPU count.
Use nproc with a higher priority if available to get the container's
allocated CPUs instead of the non-accessible host count.
`AddRequiredTargetC(xx)` feature didn't take the default compiler
standard into account, which possibly resulted in the use of an older
standard when some features requested it.
Fixes: #18686
The `FindOctave` module added by commit 170bcb6fdc (FindOctave: Add
module to find GNU octave, 2018-11-17, v3.14.0-rc1~283^2) has a few
problems in its implementation that need to be worked out before the
module can be included in a CMake release. These were missed during
review. Remove the module for now. It can be restored later with a
fresh review.
Issue: #18991
d9d285c5ad jsoncpp: Fix include order for build within CMake
0d489fab19 libuv: fix atomic ops compilation with xlclang
1699f5c231 Utilities: Suppress warnings in third-party code when using XLClang
f709089d84 XLClang: Extract compiler implicit include directories
5c41386357 XLClang: Add policy CMP0089 to present as XL for compatibility
8278237933 XL: Remove overlap with the new XLClang compiler ID
6f5cf2d2c6 XL: Revert "Recognize compilers identified by __ibmxl__"
90c6156aa8 XLClang: Add a new compiler ID for the clang-based XL compiler
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2921
In commit dc6888573d (Pass EXCLUDE_FROM_ALL from directory to targets,
2019-01-15, v3.14.0-rc1~83^2) all `AddNewTarget` call sites were updated
to copy the directory-level `EXCLUDE_FROM_ALL` into the target property
of the same name, except that the one for `include_external_msproject`
was incorrectly missed. Add it now.
Furthermore, refactoring in commit b99129d2d8 (ENH: some code cleanup,
2007-03-12, v2.6.0~2020) accidentally set the `EXCLUDE_FROM_ALL` target
property of `include_external_msproject`-generated targets to `FALSE`
instead of simply leaving it unset. This was not necessary but had no
effect until the above commit gave it a meaning. Drop that.
Fixes: #18986
When using a VS generator with `-T llvm`, MSBuild relies on the "LLVM
Compiler Toolchain" VS Extension. This does not put `clang-cl` in the
`PATH` inside the build, and LLVM no longer provides a `cl` replacement
either. Therefore we need another way to extract the path to the
`CMAKE_{C,CXX}_COMPILER`. Fortunately the LLVM VS integration provides
a `$(ClangClExecutable)` macro we can reference to get the path.
Fixes: #18983
In commit e9a1ddc594 (FindThreads: Replace the pthread symbol checking
in libc., 2018-11-18, v3.14.0-rc1~292^2) we switched to checking for
`pthread_kill` in libc but did not update the symbol check's header file
to match. Add `signal.h` to get `pthread_kill`. Keep `pthread.h`
anyway since the purpose of the check is to verify that the pthread API
works.
Fixes: #18984
Chuck Atkins
NeroBurner
Brad King
Mathieu Garaud
Kyle Edwards
Zsolt Parragi
Sebastian Holtermann
Sylvain Joubert
Craig Scott
Kitware Robot
Artur Ryt