e7f7bff4f5 Kate: improve the way the VCS-specific files are searched
96389b4cd3 Kate: add support for hg and fossil
4c32623f5f Help: fix typo in docs for set_property()
9a7612d2d0 Kate: make it possible to force a mode for the "files" entry
8a7aa2642b Help: add documentation for Kate-related variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8154
d3ece40602 Help: cmake (1): remove -E server as not available
b19036d8b3 Help: CheckSource{Compiles,Runs}: fix typo and clarify
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8164
This variable has been provided since commit 746906242d (Android: Detect
NDK version number, 2021-02-26, v3.20.0-rc3~1^2~3) when using CMake's
NDK support or the modern NDK toolchain file. Since commit 005e2cdfb0
(Android: Do not use gold for ndk >= r22, 2021-02-26, v3.20.0-rc3~1^2)
we need the value in our compiler/platform information files, so provide
it when using the NDK legacy toolchain file too.
Revert commit 1c86e397fe (Android/Clang: Tolerate undefined
CMAKE_ANDROID_NDK_VERSION, 2022-09-16, v3.25.0-rc1~118^2) since the
variable should now always be defined.
Issue: #21772Fixes: #24386
By default, kate will try to autodetect whether the project is
a svn or git checkout or not.
In case this does not give a satisfying result, the user can now
set CMAKE_KATE_FILES_MODE to the mode he wants.
Update the change from commit 2a94c762ed (FindCUDAToolkit: Add support
for CUDA::nvrtc_static, 2023-01-20, v3.26.0-rc1~55^2). The lib is named
`libnvrtc-builtins_static.a`, not `libnvrtc_builtins_static.a`.
8f82e755f3 Ninja: Fix detection of MSVC showIncludes prefix in Italian
d6e7e4d4a1 Tests: Extend RunCMake.Ninja ShowIncludes cases to cover more languages
9596305c0b Tests: Generalize RunCMake.Ninja ShowIncludes test infrastructure
c6dd4fa21d Tests: Extend RunCMake.Ninja ShowIncludes case with sample path
a9d97492fd Ninja: Record showIncludes detection in configure log
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8129
Before this patch, the write_basic_package_version_file() function of
the CMakePackageConfigHelpers module always emitted an architecture
check, even if the ARCH_INDEPENDENT option was specified. While this is
not an issue when configuring builds, as the check is skipped, this can
create issues when the "arch independent" version files are installed in
the datadir (e.g. /usr/share) in a MultiArch environment like Debian,
where different architecture packages of the same libraries can be
coinstalled; as the amd64 version of a given library contains "8 * 8"
in the file, while the i386 one contains "4 * 8", there's a conflict, as
files in /usr/share are expected to be identical across architectures.
This patch fixes this issue by only emitting the architecture check code
if needed; when ARCH_INDEPENDENT is specified, no code is written at
all.
Here's a diff between the version files generated before and after this
patch:
diff -u old/indep.cmake new/indep.cmake
--- old/indep.cmake 2023-01-29 13:43:04.840671117 +0100
+++ new/indep.cmake 2023-01-29 13:57:28.475191551 +0100
@@ -52,19 +52,3 @@
endif()
-# if the installed project requested no architecture check, don't perform the check
-if("TRUE")
- return()
-endif()
-
-# if the installed or the using project don't have CMAKE_SIZEOF_VOID_P set, ignore it:
-if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "" OR "8" STREQUAL "")
- return()
-endif()
-
-# check that the installed version has the same 32/64bit-ness as the one which is currently searching:
-if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
- math(EXPR installedBits "8 * 8")
- set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
- set(PACKAGE_VERSION_UNSUITABLE TRUE)
-endif()
diff -u old/no-indep.cmake new/no-indep.cmake
--- old/no-indep.cmake 2023-01-29 13:42:05.010710508 +0100
+++ new/no-indep.cmake 2023-01-29 13:57:40.914237219 +0100
@@ -52,13 +52,8 @@
endif()
-# if the installed project requested no architecture check, don't perform the check
-if("FALSE")
- return()
-endif()
-
# if the installed or the using project don't have CMAKE_SIZEOF_VOID_P set, ignore it:
-if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "" OR "8" STREQUAL "")
+if(CMAKE_SIZEOF_VOID_P STREQUAL "" OR "8" STREQUAL "")
return()
endif()
Fixes: #24375
- With this change we can use e.g. ImageMagick::Magick++ directly
in targt_link_libraries.
- This change also adds CFLAGS which was missing before.
- Also adds example on how to use the targets.
This add correct Open Watcom support for 16-bit Windows 3.x.
It replace existing strange mixture with WIN32 stuff which implement 16-bit Windows target partially as part of WIN32 stuff.
Now pre-defined OS ID Windows3x is used instead of confusing WIN32.
It support properly 16-bit and 32-bit application for 16-bit Windows host.
32-bit applications are build with OW WIN386 extender.
It is used similar as for other platforms by set CMAKE_SYSTEM_NAME=Windows3x and CMAKE_SYSTEM_PROCESSOR=I86 for 16-bit application or CMAKE_SYSTEM_PROCESSOR=x86 for 32-bit WIN386 extender application running on 16-bit Windows 3.x.
CMAKE_SYSTEM_NAME=Windows is used only for WIN32 applications.
Improve detection of missing compiler flags: move "argument unused
during compilation: .*" pattern from language-specific branches into
the common list.
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).
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.
If `OpenMP_<lang>_INCLUDE_DIR` is defined, add it to the list of include
directories before checking flags. Previously, this variable was
ignored for all compilers but AppleClang, despite the documentation
mentioning it as one of the possible inputs.
Fixes: #24260
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.
Máté Ferenc Nagy-Egri