8d4e510a44 Merge branch 'backport-cxxmodules-ninja-1.11' into cxxmodules-ninja-1.11
7abddcab08 Ninja: require Ninja 1.11 for C++ module support
0512428ad9 Ninja: require Ninja 1.11 for C++ module support
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8099
The example shown in the module documentation for
CMakePackageConfigHelpers was showing its age, by:
1. Hardcoding directory prefixes (`etc/`, `lib/`, etc.) instead of
using GNUInstallDirs
2. Handwaving `set()` commands (incorrectly!) as:
`set(VAR dir/ ... CACHE )`
which should, at the very least, be:
`set(VAR dir/ CACHE ... )`
3. Installing CMake configuration files to `lib/Foo/cmake/`, when
current practice favors `${CMAKE_INSTALL_LIBDIR}/cmake/Foo/`
This updated example addresses all of those issues.
before this change, pkg_check_modules(.. IMPORTED_TARGET GLOBAL)
is used for creating an imported target from which another imported
interface library named OpenSP::OpenSP is created. but pkg-config
does not account for all of CMake's other search behavior controls,
such as CMAKE_FIND_ROOT_PATH. neither does it export the full path
with OpenSP_LIBRARY.
after this change, the paths found by pkg-config are only used
as hints for the find_*() commands. and some cleanup are included:
* be QUIET when calling find_package(PkgConfig ..) and
pkg_check_modules(..) as they are distracting from user's point of
view. what matters is the output of find_package_handle_standard_args()
* parse the version and check for the existance of symbol as long as
header path is found. because they only use header files.
* define OpenSP_LIBRARY as long as it exists. this just follows
the convention. as OpenSP_FOUND implies a valid OpenSP_LIBRARY.
* wrap and intent multi-line command calls for better readability
* check OpenSP_FOUND before adding OpenSP::OpenSP, it's more
idiomatic.
Fixes: #24313
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
This patch adds support for tracking the swiftmodules for executables
exporting symbols.
This fixes a bug in the earlier implementation around emitting the
swiftmodule. Previously, the code would use
`CMAKE_EXE_EXPORTS_Swift_FLAG` to inject the `-emit-module`, and module
path information into the `CMAKE_Swift_LINK_EXECUTABLE` rule. Because
Swift skips the build step and only runs during the link phase, these
flags were injected in `cmNinjaNormalTargetGenerator::ComputeLinkCmd`
instead of `cmLocalGenerator::GetTargetFlags` where it is done normally.
Unfortunately, injecting in `ComputeLinkCmd` didn't do anything because
we have a `linkCmd` so `ComputeLinkCmd` exits early, before the
EXE_EXPORT flags get added to the link command.
Instead of playing with that flag, CMake checks
`CMAKE_Swift_LINK_EXECUTABLE_WITH_EXPORTS` and uses that as the link
rule if it exists and falls back on `CMAKE_Swift_LINK_EXECUTABLE`. I've
defined that variable in terms of `CMAKE_Swift_LINK_EXECUTABLE` with the
necessary additional flags for emitting the swift module instead. This
has the same end effect as the desired behavior, but simplifies things a
bit.
Since we're generating the swiftmodule for executables with exports,
I've also updated the dependency graph to include the swiftmodule as an
output in the build dependency graph if the executable has exports.
Tests updated:
- RunCMake/NoWorkToDo:
Ensure that the build graph does not result in unnecessary rebuilds
with exporting executables.
- SwiftOnly:
Ensure that we can consume functions defined in the executable by a
library getting linked into said executable.
Prior to CMake 2.8.4 (released in 2011), we defined `WIN32` on CYGWIN.
That was removed, but an undocumented `CMAKE_LEGACY_CYGWIN_WIN32`
compatibility mode was left to help projects transition. Only projects
that do not require at least 2.8.4 as their minimum CMake version need
the compatibility mode. We've also long warned about projects that do
not require at least 2.8.12, so it is now reasonable to remove the
legacy compatibility mode.
Since commit 18e1bfbb3c (cmake: On configure error suggest looking at
CMake*.log files, 2013-07-09, v2.8.12~210^2), when configuring a project
fails, we print `See also .../CMake{Output,Error}.log` near the end of
the output. This was intended to help users find failures in system and
compiler inspection checks, but for normal project errors the messages
may be misleading. The logs may contain incidental errors that are part
of normal operation and do not need to be addressed by the user.
Since commit f6ed2585e5 (Modules: Record system inspection steps in the
configure log, 2023-01-16), CMake's builtin modules no longer log
information to the old-style `CMake{Output,Error}.log` files anyway,
so stop mentioning them.
Fixes: #22131
Issue: #23200
f6ed2585e5 Modules: Record system inspection steps in the configure log
0f688386ea Modules: Drop redundant check logging to CMakeOutput.log and CMakeError.log
ecc26f98eb UsewxWidgets: Remove leftover debugging code
874c2e1198 FindQt4: Drop outdated advice to look at CMakeError.log on failure
a80465bcad GHS: Drop debugging message from log
9199449687 CompileFeatures: Warn explicitly when feature detection binary is not found
24ccc8c3c9 CompilerId: Restore logging of failed identifications
95976514f6 Tests: Avoid using CMake{Output,Error}.log files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8089
