41f4e1c457 CMakePackageConfigHelpers: Document PACKAGE_PREFIX_DIR for public use
c5231ba29e find_package: Save/restore PACKAGE_PREFIX_DIR
8ac7958e3a generate_apple_*_selection_file: Save/restore PACKAGE_PREFIX_DIR
bf88879f1f generate_apple_architecture_selection_file: Avoid early returns
a4ac2c92f4 Help: Add missing section heading for apple architecture selection
b7fcc44be9 Help: Fix CMakePackageConfigHelpers typos, grammar and formatting
f1cacaa830 Tests/RunCMake/CMakePackage: Define variable closer to where it is used
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9430
Package configuration files generated by `configure_package_config_file`
set this variable in `@PACKAGE_INIT@` and then use it later. There may
be intervening calls to `find_package`, e.g., via `find_dependency`.
If the loaded package also used `configure_package_config_file`, it
may change the value of `PACKAGE_PREFIX_DIR`. Explicitly save and
restore the value to avoid this.
Fixes: #25827
Filter out `-Wunused-command-line-argument` warnings from Clang (that
can be caused by user-specified flags) so that they do not break our
checks for C++ feature availability.
This extends commit 71b65abca2 (C++ feature checks: Filter out warnings
caused by user flags, 2017-09-19, v3.10.0-rc1~90^2).
Wire up the flags needed to support module libraries built and used with
Swift. We need to pass `-bundle` to the linker when linking module
libraries on Darwin, and we need to pass `-export-dynamic` to the linker
when emitting an executable that exports symbols on Linux. This patch
wires up `CMAKE_SHARED_MODULE_CREATE_Swift_FLAGS` and
`CMAKE_SHARED_MODULE_LOADER_Swift_FLAG` on Darwin, and hooks up
`CMAKE_EXE_EXPORTS_Swift_FLAG` on Linux in order to support passing
things correctly.
We can't expose `CMAKE_EXE_LINKER_FLAGS` to Swift, as it contains flags
that the Swift compiler doesn't recognize, but the other
language-specific variables are safe to expose.
In commit ff6c401309 (cmTarget: Add interface for compatible numeric
properties, 2013-10-22, v3.0.0-rc1~460^2) the condition
dagCheckerParent && !dagCheckerParent->EvaluatingLinkLibraries()
was written that way to avoid a nullptr dereference, but is actually
meant to say "is not evaluating link libraries". That can also be true
when there is no `dagCheckerParent`, such as when evaluating a generator
expression outside of usage requirements, e.g., for `add_custom_target`.
The original commit tried to account for that by duplicating the
implementation in another code path, but that did not work in all cases.
Fix the condition, remove the duplication, and enable tests for the
now-working cases.
The `IsLinkInterfaceDependent*Property` methods internally exclude
INTERFACE libraries since commit 0bfcb450e6 (INTERFACE_LIBRARY: Avoid
codepaths which set unneeded properties., 2013-11-20, v3.0.0-rc1~301^2~1).
For `import std;` support, CMake needs to know the standard library
involved in order to ensure that the right target is linked. Afterwards,
the created synthetic targets need their target compile features
computed.
8fd089018d Tests/RunCMake/cmake_language: test GET_EXPERIMENTAL_FEATURE_ENABLED
46da8e64b0 cmCMakeLanguageCommand: use `cmExperimental::FeatureByName`
e8582abc6d cmExperimental: add support for getting a feature value from its name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9414
Kitware Robot