Add setup of system include directories to language related macro to remove extra lines for C and CXX.
System include directories are always same for both languages (they are defined per platform).
Document and add explicit tests for empty string input:
`if(EXISTS "")` and `if(IS_DIRECTORY "")` are always false.
This avoids need for users to do extra checks due to
CMake non-short-circuit logic as below:
if("${p}")
if(EXISTS "${p}")
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.
Ensure that we're actually trying to rebuild libB when the public
interface for libA changes. Without handling the swiftmodule dependency
edge correctly, we would only get a linker error because libA didn't
have the symbol that libB depended on. With the fix, we get a proper
compiler error because ninja knows to rebuild the intermediate libB
when the public interface of libA changes. This is more actionable.
Swiftmodules act like headers for Swift, but are generated by the
compiler while building the module. Unlike headerfiles in a pure C/C++
world, where the compiler generates the appropriate depfile. We don't
have We're
already adding the swiftmodule as an output from swift-linked targets,
but aren't using that on inputs.
This dependency edge is most important for static libraries in
incremental builds. Suppose we have two static libraries, A, and B, and
an executable E. B "links" against A, and E links against B. In a C/C++
environment, the library link dependency edge will run from E to both A
and B, but there won't be an edge from B to A. If A is changed, the only
way this should affect B is if the public interface changes, in which
case, the headers will also change. The dep file contains the header
link, so Ninja will rebuild B when appropriate. With Swift in an
incremental build, B sees the order-dependency on A, but A already
exists. If A is changed in a way that changes the public interface, the
swiftmodule will change, but since we don't track it, we don't rebuild
B, resulting in the final executable to fail to link.
In order to handle determining the swiftmodule name to add to the ninja
dependency graph, we'll need to be able to compute the swiftmodule name
for the dependency target, not just the current target. This patch
refactors the computation of the module name out of inaccessible lambdas
and into static functions that can compute the swiftmodule name from the
generator and the target.
INSTALL_NAME_DIR now mentions BUILD_WITH_INSTALL_NAME_DIR.
The INSTALL_NAME_DIR, INSTALL_RPATH and $<TARGET_RUNTIME_DLLS:tgt>
documentation now mention the other two platforms respectively, to
make it easier for developers who are not familiar with all three platforms,
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>
