In order to shorten the download failure of ExternalProject download
steps, a download retry is only done when a recoverable network
error is encountered.
A valid HDF5 installation with the "high level" extensions not
configured will *fail* to be correctly detected by CMake since
commit d9e39f3f89 (FindHDF5: check that compiler wrapper can
compile a minimal program, 2020-02-10, v3.18.0-rc1~744^2~1):
```
/.../hdf5/cmake_hdf5_test.c:2:10: fatal error: 'hdf5_hl.h' file not found
```
This does not stop the configuration but does prevent flags and
libraries from being recognized.
Change the default value of `CMAKE_AUTOMOC_PATH_PREFIX` to `OFF` to
restore compatibility with behavior of CMake 3.15 and below.
C++ source files that are generated by Qt's meta object compiler (moc)
include the header file that was passed as input argument to moc. This
is usually a path relative to the source directory, for example
#include "../../source/dir/myobject.h"
That is problematic for reproducible builds as described in #18815.
To cope with that, the target property AUTOMOC_PATH_PREFIX was
introduced in CMake 3.16 by commit d018d27c10 (Autogen: Add moc path
prefix generation (AUTOMOC_PATH_PREFIX), 2019-09-13, v3.16.0-rc1~94^2~4).
The property is default-initialized from the variable
`CMAKE_AUTOMOC_PATH_PREFIX`, which defaults to `ON`.
If this property is ON, and myobject.h is located in an include
directory of the target, moc-generated C++ files include the file
without the "path prefix":
#include "myobject.h"
This behavior, however, can break projects that have equally named
header files in different include directories. As "not breaking
existing projects" trumps "have reproducible builds by default" we
change the default of `CMAKE_AUTOMOC_PATH_PREFIX` to `OFF`.
Also, it is now possible to pass `-DCMAKE_AUTOMOC_PATH_PREFIX=ON` on the
CMake command line. Before, it was overridden in `CMakeGenericSystem`.
Fixes: #20598
Issue: #18815
Starting with Xcode 12 the arm64 architecture is supported
as an iOS device as well as simulator architecture.
But the fat macho file format does not distinguish by SDK,
only by architecture. That makes lipo (rightfully) complain
that it cannot add both architectures to a single file.
To work around we make sure that both SDKs are built for a
disjoint set of architectures. If an architecture is present
for both SDKs we prefer the currently configured one.
The log output has been extended to reflect that:
```
[iOS combined] Architectures (iphoneos): arm64 arm64e armv7 armv7s
[iOS combined] Architectures (iphonesimulator): arm64 arm64e i386 x86_64
[iOS combined] Architectures (iphonesimulator) after pruning: i386 x86_64
```
Since commit e672db628b (FindRuby: Rename variables to match case of
module name, 2020-03-11, v3.18.0-rc1~546^2), the result variables named
with the old `RUBY_` prefix are provided by compatibility code that maps
from the new `Ruby_` prefix variables. There is no `Ruby_INCLUDE_PATH`
variable, so do not try to map it to `RUBY_INCLUDE_PATH`. The latter is
provided by dedicated compatibility code left from before that
transition.
Fixes: #21064
On Linux and macOS, absolute paths start with `/` which may be
interpreted by clang-cl as an option. To avoid this, we separate the
source file path from preceding options with `--` to tell `clang-cl` it
is not an option.
ecc1961768 FindTclsh: Drop Cygwin-specific behavior and use POSIX code path
af666acdf4 FindOpenGL: Drop Cygwin-specific behavior and use POSIX code path
8edbc59e46 install: Use case-sensitive pattern matching on Cygwin
24482499ea FindPerlLibs: Add versioned perl library name for Cygwin
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5092
Various find modules include each other to delegate finding some subset
or variant of the package. Ideally, these would use `find_dependency` or
some other actual `find_package` mechanism, but that is a larger change.
Instead, just detect inclusion and suppress FPHSA name mismatch
warnings.
Fixes: #21060
Do not set the policy version before recording our internal macros such
as `__Python_add_library`. Otherwise callers get our policy version
instead of theirs. Instead just set the specific policies we need.
Also fix one case in our test suite where we were accidentally
relying on the policy version to be set by `FindPython`.
Fixes: #21042
f76c20da63 Toolchain: Test compiler initial settings
db486da265 Toolchain: Update documentation for initial compiler flags
deec2f587c Toolchain: Take CMAKE_<lang>_FLAGS_INIT into account during compiler detection
ca899af3e2 Toolchain: Handle repeated invocations of CMake with -DCMAKE_C_COMPILER
12ba89e142 Toolchain: Make `/path/comp;-argn' behave the same as 'comp;-argn'
6f1af899db Toolchain: Capture all arguments from CMAKE_<LANG>_COMPILER
ec1d3bc0b6 cmake: avoid exception when printing "changed variables" message
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4136
Refactoring in commit 889a7146ff (GoogleTestAddTests: Refactor into
callable method, 2020-03-16, v3.18.0-rc1~450^2~3) accidentally
parsed `TEST_EXECUTOR` as a single-value argument instead of a list.
When a CUDA sdk doesn't have nvcc, defer to the existence of
a version.txt file. When we do this fall back we also reconstruct
the CUDA version via version.txt
Fixes#20643
When using `cmake ... -DCMAKE_C_COMPILER=gcc;-pipe` first invocation of
CMake worked correctly.
When using `cmake ... -DCMAKE_C_COMPILER=/path/to/gcc;-pipe` first
invocation of CMake detected a change to CMAKE_C_COMPILER, printed "You
have changed variables" message, and re-ran the initial compiler tests
after configuration was complete and before generation of the project
files.
The difference was due to the cache being forced updated with the new
value of CMAKE_C_COMPILER so that the comparison check passes.
The generated ..._include.cmake file contained an inclusion of
GoogleTestAddTests without any path. In general, this is a good
approach since it enables to correctly catch possibly
user-customized files.
However, in this case, it didn’t work this way since the
..._include.cmake file is evaluated by a separate CMake call under
a custom command. Because of this, the CMAKE_MODULE_PATH is not set
as expected by the user and the said inclusion catches CMake own
version of the module rather than the possibly user-customized one.
This change fixes this by making the inclusion with an absolute path
determined upon the ..._include.cmake file generation.
During compiler identification, if CMAKE_{C,CXX}_COMPILER_TARGET is
defined, the corresponding clang target flag is used to guaranty proper
target architecture detection.
Fix logic added by commit fc5afbe970 (FindCURL: support COMPONENTS to
check features, 2018-11-28, v3.14.0-rc1~287^2~2).
When searching for particular components and `curl-config` reports one of
the components being searched for first in the list, `find_package` fails.
This is due to the check that treats non-zero index in the list as success
and zero index as failure, while documentation on `list(FIND)` states that
failure to find an element results in return value of -1 (not 0). I'm
hitting this when building cURL with support for HTTP and HTTPS protocols
only, and then trying to `find_package(CURL COMPONENTS HTTP HTTPS)`.
I'm using `if(NOT x EQUAL -1)` check form as it appears to be the most used
throughout the modules.
While fixing this issue I've looked through all the uses of `list(FIND)` in
other modules but wasn't able to find improper use except here.
Since commit 8cc384f629 (Compilers: Add paths from -print-sysroot to
system prefix path, 2020-03-25, v3.18.0-rc1~337^2) we prepend the
compiler's sysroot to `CMAKE_SYSTEM_PREFIX_PATH`. This does not
make sense when the prefix is just `/`, such as on Ubuntu 16.04's
system compiler.
Fixes: #21019
Brad King