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.
In commit b795c96727 (CPack/NSIS: Fix uninstall command when run from
installer, 2022-03-21, v3.23.0-rc5~9^2~1) we incorrectly removed the
`_?` parameter when calling the uninstaller during installation.
This parameter is however essential for ExecWait to actually wait for
the uninstaller to finish. Without it, the uninstaller is started in
the background and installer and uninstaller run at the same time.
See https://nsis.sourceforge.io/Docs/Chapter3.html#installerusageuninstaller
Add back the `_?` parameter to fix this regression. Use another
approach to solve the problem motivating the original change.
Fixes: #24041
Craig Scott