* When both debug and optimized libraries are found, the corresponding
keywords were getting de-duplicated and breaking.
* CMake's link line generation de-duplicates in many cases anyway.
* Other find modules do not explicitly de-duplicate in general.
Fixes: #21670
Use `list(REMOVE_DUPLICATES)` directly. For definitions the order
doesn't matter. For include directories it is better to remove late
duplicates than early duplicates.
39cbbb59a5 ninja: add experimental infrastructure to generate gcc-format modmap files
791b4d26d6 ninja: add experimental infrastructure to generate modmap files with dyndep
4b23359117 ninja: Add experimental infrastructure for C++20 module dependency scanning
f814d3b3c6 cmNinjaTargetGenerator: use $OBJ_FILE for the object
b0fc2993e1 Treat the '.mpp' file extension as C++ code
988f997100 cmScanDepFormat: Fix name of our internal tool in parse errors
dacd93a2db ninja: De-duplicate version numbers required for ninja features
533386ca29 cmStandardLevelResolver: Factor out helper to capture stoi exceptions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Acked-by: Shannon Booth <shannon.ml.booth@gmail.com>
Merge-request: !5562
In systems where PostgreSQL has separate developer packages for
server and client libraries `PostgreSQL_TYPE_INCLUDE_DIR` is not
specified. According to initial logic server part was not required
but was accidentally added to `REQUIRED_VARS` during the migration to
`find_package_handle_standard_args`.
Fixes: #17223
Use `target_link_libraries` to set `INTERFACE_LINK_LIBRARIES` so that
the `debug` and `optimized` keywords work.
In commit a8e0a6b3e4 (FindHDF5: Port changes from VTK, 2020-06-10,
v3.19.0-rc1~312^2~1) we added use of `HDF5_LIBRARIES`, but the value may
contain `debug` and `optimized` keywords.
Fixes: #21637
Since 3.19, CMake generates a deprecation warning when using a minimum
version less than 2.8.12. This eliminates those warnings generated
during tests, which are typically hidden from the user and developer but
are being generated nonetheless.
When doing an ExternalProject superbuild with all output logged to
files, the output currently looks as follows:
```
[652/904] Performing install step for 'plasma-framework'
-- plasma-framework install command succeeded. See also /root/build/kde/frameworks/plasma-framework/log/plasma-framework-install-*.log
[658/904] Performing build step for 'khtml'
-- khtml build command succeeded. See also /root/build/kde/frameworks/khtml/log/khtml-build-*.log
[659/904] Performing install step for 'khtml'
-- khtml install command succeeded. See also /root/build/kde/frameworks/khtml/log/khtml-install-*.log
[661/904] Performing configure step for 'krunner'
-- krunner configure command succeeded. See also /root/build/kde/frameworks/krunner/log/krunner-configure-*.log
[661/904] Performing build step for 'krunner'
```
More specifically, because a success line is printed for every
succeeded step, we lose the advantage of Ninja's progress bar
which will now also print a new line instead of updating the same
link as happens when using Ninja in a normal CMake project.
By silencing the success message when using the Ninja generator,
Ninja's progress bar works as expected and updates inline instead
of printing a new line for each progress update.
With this change, the above output is reduced to a single line
progress bar:
```
[661/904] Performing build step for 'krunner'
```
9c360b9eea FindMatlab: Fix search for MCR
bda5e2ac8f FindMatlab: Only include engine and dataarray libraries if they are found
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5600
b7f0327dcd Tests: Cover macOS host architecture selection on Apple Silicon hosts
5f882f6ce5 macOS: Offer control over host architecture on Apple Silicon hosts
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5589
Since commit b6c60f14b6 (macOS: Default to arm64 architecture on Apple
Silicon hosts, 2020-09-28, v3.19.0-rc1~63^2) we use `sysctl` to detect
that we are running on Apple Silicon in a way that pierces Rosetta.
This always sets `CMAKE_HOST_SYSTEM_PROCESSOR` to be `arm64` on such
hosts. However, macOS offers strong support for running processes under
an emulated `x86_64` architecture.
Teach CMake to select either `arm64` or `x86_64` as the host
architecture on Apple Silicon based on the architecture of its own
process. When CMake is built as a universal binary, macOS will select
whichever slice (architecture) is appropriate under the user's shell,
and `CMAKE_HOST_SYSTEM_PROCESSOR` will match.
Also offer a `CMAKE_APPLE_SILICON_PROCESSOR` variable and environment
variable to provide users with explicit control over the host
architecture selection regardless of CMake's own architecture.
Finally, if `CMAKE_OSX_ARCHITECTURES` is not set, pass explicit flags to
the toolchain to use selected host architecture instead of letting the
toolchain pick.
Fixes: #21554
7808cbd644 CMakeDetermineCompilerId: support Intel DPC++ compiler toolset for VS gen
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5579
