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.
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
Replace old-style `file(APPEND .../CMake{Output,Error}.log)` logging
with calls to `message(CONFIGURE_LOG)` to record the steps in the
`CMakeConfigureLog.yaml` configure log instead.
Issue: #23200
`try_compile` and `try_run` now automatically log checks using them to
`CMakeConfigureLog.yaml`.
Add `LOG_DESCRIPTION` arguments to some `try_compile` calls to
replace the description previously written to the old logs.
Issue: #23200
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 15.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Fixes: #24315
44abf24848 Swift: Add comment about where platform-specific flags should go
9a013c9e9d Swift: Use macOS-style linker flags on iOS, tvOS, and watchOS too
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8070
Without this, building a shared Swift library with `CMAKE_SYSTEM_NAME=iOS`
produces the error `ld: unknown option: -soname`. iOS is an Apple platform,
and so should use the `-install_name` option.
The IntelLLVM compiler, for compatibility with MSVC on Windows, always
runs with support for at least C++14. The `-Qstd=c++11` flag just
causes a warning that it is unused.
Fixes: #24316
Update the logic added by commit ef41d49812 (Fix implicit include
directory extraction for adaptive relative paths, 2019-04-08,
v3.14.2~5^2) to account for the new `try_compile` work directory used
for the ABI check since commit 2edf0fc6d7 (Modules: Use new
keyword-dispatched try_compile signature, 2022-09-13,
v3.25.0-rc1~144^2).
Paths relative to the work directory will now have one more `../`
in them, so update the test data to match.
Fixes: #24279
Intel oneAPI 2023.0 added the `icpx` compiler front-end on Windows.
It uses a GNU-like command-line, and is not yet supported by CMake.
Avoid finding `icpx` as the CXX compiler on Windows until support
is added.
Fixes: #24266
Issue: #24314
Update the list of known versions.
There is a new header-only library, Boost.URL. It has no
dependencies and has a core header `<boost/url.hpp>`.
Run the command
cmake -DBOOST_DIR=/path/to/boost_1_81_0 \
-P Utilities/Scripts/BoostScanDeps.cmake
to extract dependencies from the 1.81.0 source tree.
They are the same as 1.80's dependencies, so just update
the version check for warning about newer versions.
