The implicit include directory extraction added by commit 5990ecb741
(Compute implicit include directories from compiler output, 2018-12-07,
v3.14.0-rc1~108^2) leaves paths like `/usr/lib/../include` unchanged.
Fix the logic to canonicalize such paths (e.g. to `/usr/include`)
as we do for implicit link directories already. This is important
to ensure the set of implicit directories is represented in the same
form as the include directories that will be compared to them.
Issue: #19095
Both commit 88ecfd8ba1 (CPackIFW: Add some options, 2016-11-11,
v3.8.0-rc1~248^2) and commit e5089c562c (CPackIFW: Add some options,
2017-01-24, v3.8.0-rc1~53^2) added some options to this macro's
documentation and implementation, but the actual processing of the
parsed options was never added. Add it now.
Reviewed-by: Konstantin Podsvirov <konstantin@podsvirov.pro>
Our documented standard for find module variable names is to match the
case of the find module package name. This was overlooked when the
module was added by commit 84e7920b3a (FindFontconfig: Add module to
find Fontconfig, 2018-09-27, v3.14.0-rc1~523^2).
The module was released with the upper case names in CMake 3.14.0, so
fix it to have camel case names in 3.14.1. This is incompatible but
anyone using a given release series should be using the latest patch on
it and we've made breaking fixups on newly released features like this
before.
Reported-by: Christophe Giboudeaux <christophe@krop.fr>
Fixes: #19094
Any `include_directories()` calls in toolchain files are used during our
ABI detection step even though it does not include any system headers.
Since commit 5990ecb741 (Compute implicit include directories from
compiler output, 2018-12-07, v3.14.0-rc1~108^2), that check is also used
to detect implicit include directories. Any `include_directories()` in
a toolchain file are detected as implicit and later excluded from
explicit specification on compiler command lines, thus breaking the
purpose of the calls in the first place.
Fix the implicit include directory detection step to avoid using paths
from `include_directories()` calls in the toolchain file.
Fixes: #19079
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.
Update the component added by commit 513e77550d (FindPython: Introduce
NumPy component, 2018-12-12, v3.14.0-rc1~95^2). The `numpy/`
sub-directory should not be part of the include directory. It should be
part of the `#include` line.
Java 9 restructured the standard location of the AWT libraries due to
the removal of the JRE/JDK separation. We should check all possible
combinations of subdirectories to the Java root directories to ensure
that the libraries will be found after an upgrade.
Furthermore, a root directory would contain both, include and library
paths, so the search should be unified to ease maintenance on the
module.
In commit b6f6cac378 (ExternalProject: add LOG_DIR option that allows
overriding of log location, 2018-10-12, v3.14.0-rc1~515^2~1) the log
directory got its own option. The intention was to fall back to the
stamp directory by default. However, the implementation actually only
falls back to the same default as the stamp directory and does not
consider a custom stamp dir.
Update the default log dir computation to fall back to whatever is the
final selection for the stamp dir.
Fixes: #19000
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.
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
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
MS-style command-line tools accept either `/` or `-` for command-line
options. Prefer `-` over `/` so that non-MS tools do not treat it as a
path.
Fixes: #18941
In commit 1293ed8507 (ParseImplicitIncludeInfo: keep implicit incl.
consistent when rerunning cmake, 2019-01-30, v3.14.0-rc1~26^2) we did
not account for `CMAKE_<LANG>_STANDARD_INCLUDE_DIRECTORIES`. This
variable lets platform modules or toolchain files specify directories
that are to be explicitly passed as standard include directories. These
include directories are used by the test project from which we extract
implicit include directories so they appear in the parsed results
whether or not the compiler really considers them implicit. Exclude
these entries from the computed implicit include directories since they
are not actually implied by the compiler when we invoke it with
"standard" include directories passed explicitly.
Instead teach the build system generators to treat the "standard"
directories as implicit for purposes of excluding them from appearing
earlier in the compiler command line due to `include_directories` and
`target_include_directories` calls.
Issue: #18936, #18944
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 output is only merged for a step if it is logging to file. This
option is ignored for steps that are logging normally.
A minor grammatical error has also been fixed as part of this change.
The quoting added by commit 8c5221fb1f (try_compile: Preserve special
characters in COMPILE_DEFINITIONS, 2019-01-21, v3.14.0-rc1~108^2~3)
broke the case that the `COMPILE_DEFINITIONS` value contains a `;`.
Without the quoting the `;` would be generated literally in an unquoted
argument in the test `CMakeLists.txt` file and would then be expanded.
With quoting the `;` is preserved, which is not the old behavior.
Fix this by expanding the `;`-list ahead of time. Add test cases for
behavior with both `#` and `;`.
This was noticed with the PGI compiler where we set
`CMAKE_CXX*_STANDARD_COMPILE_OPTION` to values like `--c++17;-A`. The
symptom had also been observed while preparing commit ef8f237686
(ParseImplicitIncludeInfo: add SunPro Fortran and PGI compiler, Cray
fix, 2019-01-29, v3.14.0-rc1~26^2~2) but was not recognized at the time
as a regression. Revert the workaround added by that commit.
Fixes: #18919
The naming convention for submodule files varies across compilers. Add
a table to the compiler information modules and thread the information
through to the Fortran module dependency parser. Fill out the table for
compiler ids known to support Fortran submodules.
Fixes: #18746
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.
