a0d4e3bf34 cmGeneratedFileStream: Drop unused WriteRaw method
2e5af30ce0 Ninja: Match showIncludes dependencies using console output code page
e1c1679148 cm_codecvt: Add support for the Windows console output code page
328c15189d cmGeneratedFileStream: Add support for a temporary alternate encoding
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7845
Generalize the fix from commit 37a279f8d1 (Ninja: Write msvc_deps_prefix
as UTF-8 when console codepage is UTF-8, 2020-07-31, v3.19.0-rc1~349^2).
`cl /showIncludes` output is encoded using the console output code page,
so this is the byte sequence that Ninja must use to match its lines.
Fixes: #24068
Swift is used as the linker for non-swift files because it needs to pull
files like swiftrt.o in when swift symbols are present to ensure that
the swift runtime is linked.
The swift driver uses clang as the underlying linker, which pulls in
crtbegin.o and friends when appropriate, so using Swift as a linker for
C/C++ libraries is fine.
The output-file-map was getting passed to all Swift invocations,
regardless of whether or not we generated one. This patch changes it so
that we only include the output-file-map in the Swift compiler
invocation if we have actually generated the file.
In commit a2fc4b6257 (FindGLUT: Drop the now-unnecessary exclusion of
pkg-config for multiconfig, 2022-10-13, v3.25.0-rc2~16^2) we
accidentally removed the entire condition around the `pkg-config` code
path instead of just the multi-config part.
Fixes: #24095
Previously, the build directory was not explicitly specified. Instead, the
current working directory was assumed to be the build directory and the
source directory was passed as a positional argument. However, if the
source directory contained a CMakeCache.txt, it was treated as a binary
directory instead. For the scenario where a project is built in-source and
it calls ExternalProject_Add() with its own source directory but a different
build directory (e.g. to build itself with a different set of configure arguments),
this results in a build error.
Explicitly list both the source and build directories using the -S and -B options
respectively. This unambiguously sets both, avoiding the above problem.
Fixes: #24081
3fc971c38b CheckSourceCompiles: For Swift executable, name source 'main.swift'
2345139ab5 CheckSourceCompiles: Add support for Swift
4451a1f54f Tests: Factor out a CMake_TEST_Swift variable for Swift test conditions
f78ad6223a Tests: Provide Apple inspection results to CMakeOnly and RunCMake tests
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Saleem Abdulrasool <compnerd@compnerd.org>
Merge-request: !7783
Xcode uses its own heuristics to determine whether or not to accept
top-level code in a source file while Ninja uses the swift driver
heuristics.
With the Swift driver, if the module contains a single file, that file
will be parsed as a top-level code context. With Xcode, the single file
will only be parsed as top-level code if the name of that file is
'main.swift'.
To ensure more consistent behavior between the two generators, if we're
building Swift and the try-compile target type is executable or
undefined, we name the file `main.swift` to ensure that both will handle
the single file as top-level code.
When cross-compiling for Android, the library path suffixes `/<number>/`
refer to API level specific platform libraries instead of architecture
bitness. Disable path suffix use under NDK to avoid incorrect inclusion
of API level specific libraries below the targeted API level.
Fixes: #23830
In commit 00c4f488f2 (FindJNI: support Android NDK, 2022-03-18,
v3.24.0-rc1~325^2) we used `CMAKE_ANDROID_API` to check the Android API
level. However, `CMAKE_SYSTEM_VERSION` is the authoritative value.
When cross-compiling for Android, an unset `CMAKE_ANDROID_API` can
result in failure to locate JNI because the `NativeHelper` component
cannot be found. In this case, the component is falsely assumed to be
available by default (and thus required) since the comparison against an
unset `CMAKE_ANDROID_API` variable evaluates to true. Use
`CMAKE_SYSTEM_VERSION` to determine the Android API level instead.
Issue: #23830
We need to revert this change as it can disable error messages
when compiling invalid CUDA code.
This reverts commit ea659b155d (CUDA: Always mark cuda toolkit as system
include, 2022-06-27, v3.25.0-rc1~269^2).
Serenity's LibDl was merged into LibC to simplify the build and port
infrastructure [1]. Set `CMAKE_DL_LIBS` to the empty string to match
what other platforms do. Update the platform module added by
commit 45ca894164 (SerenityOS: Add Platform module, 2022-01-02,
v3.25.0-rc1~635^2).
[1] https://github.com/SerenityOS/serenity/pull/14854
Issue: #23589
Revert commit e0a62b84b5 (FindGLUT: On Windows and with multiple config
generator do not use pkg-config, 2022-09-27, v3.25.0-rc1~69^2). We now
call `select_library_configurations()` even after using pkg-config,
which will handle the absent libraries on Debug/Release configurations.
Issue: #24028
Revert commit 8041ca5df0 (FindGLUT: Fix GLUT_INCLUDE_DIRS with
pkg-config and /usr/include, 2022-05-11, v3.24.0-rc1~151^2).
As the main code path will always do `find_path()` which respects the
`CMAKE_FIND_ROOT_PATH_MODE_INCLUDE` variable and will search in system
paths depending on that variable.
Issue: #23474, #24028
Since commit f90d15458a (FindGLUT: Use pkg-config to find flags if
available, 2021-06-11, v3.22.0-rc1~469^2), pkg-config results are used
directly. However, this is not compatible with other features of
CMake's find logic such as `CMAKE_FIND_ROOT_PATH` and per-config
results. Switch to a convention already used by pkg-config support in
other find modules, in which the pkg-config results are only used as
hints for the main search logic.
Fixes: #24028
Parse implicit link information for this compiler to support
mixed-language linking. This was missed by commit 85749766df
(LLVMFlang: Add support for LLVM Flang, 2021-07-07, v3.24.0-rc1~86^2).
Also activate mixed-language test cases that would have caught this.
Issue: #22387
Fully-optimized builds should be using whole-module optimizations(WMO)
to get all the optimizations the compiler can do for a given module.
As such, it makes sense for the release builds to pass
`-whole-module-optimization` or `-wmo` to the compiler by default.
`-whole-module-optimization` and `-wmo` are aliased and have the same
impact on the build.
Removing `-incrementa' from the `CMAKE_Swift_CREATE_*` variable:
WMO is incompatible with incremental builds, so it is removed to avoid
warnings from the Swift compiler.
Pass `-num-threads` to the driver in `CMAKE_Swift_CREATE_*`:
WMO doesn't use the `-j` flag, but instead uses `-num-threads` to get
parallelism. The two flags are applied in mutually exclusive contexts,
so `-j N` is a no-op in WMO, while `-num-threads` is a no-op in other
modes. Passing both at the same time will catch both cases without
negatively impacting the other case.
Brad King
Letu Ren
Evan Wilde
Craig Scott
Mojca Miklavec
مهدي شينون (Mehdi Chinoune)
Alex Turbov
Sergiu Deitsch
Robert Maynard
Andrew Kaster
Marc Chevrier
leha-bot
koostosh
Oleksii Odynochenko