7480fa0a5f COMPILE_DEFINITIONS property: ensure leading -D is removed in all cases
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8004
Before, a documentation entry was in/out parameter.
Now it's a normal return value.
This also makes possible to eliminate defaulted default ctor
for `cmDocumentationEntry` for C++ 11.
Also, simplify `cmake::AppendGlobalGeneratorsDocumentation()`.
Previously we selected a single "language for preprocessor" with which
to compute both target-wide `GCC_PREPROCESSOR_DEFINITIONS` and
`{HEADER,FRAMEWORK}_SEARCH_PATHS`. Since commit c0dd3dd2c1 (Xcode:
Evaluate Swift compile definitions separately, 2022-10-25,
v3.25.0-rc3~16^2) we never compute `GCC_PREPROCESSOR_DEFINITIONS` for
Swift. Therefore we need to select the language for target-wide include
and framework directories separately.
Fixes: #24116
Since commit dc5fc898f6 (Xcode: Set object file locations using
TARGET_TEMP_DIR, 2022-09-29, v3.25.0-rc1~64^2~1), `xcodebuild clean`
does not remove the object files in our explicit `TARGET_TEMP_DIR`
because it is not under the `SYMROOT`. Put it there.
Fixes: #24096
The change in commit 61acaa12af (xcode: Don't set INSTALL_PATH unless
target is SHARED_LIBRARY, 2022-07-14, v3.25.0-rc1~291^2) breaks some
existing use cases. Revert it pending further investigation.
Fixes: #24087
Issue: #15183
Xcode has a separate setting for Swift compile definitions, so we can
compute a dedicated value for it. Therefore we can:
* Support the COMPILE_LANGUAGE generator expression for Swift-specific
filters.
* Avoid passing the `=value` part of definitions, which Swift does
not support.
This revises commit 5cb625eb2f (Xcode: Pass compile definitions to
Swift, 2022-06-19, v3.25.0-rc1~493^2) and reverts commit 12c6fec6b4
(Xcode: Drop CMAKE_INTDIR= definition in Swift targets, 2022-09-30,
v3.25.0-rc1~60^2~2), as the latter is no longer needed.
Fixes: #24086
This patch sets the swift compilation mode to wholemodule in the xcode
generator for all non-debug build configurations at the project level.
Leaving the target build-configurations default ensures that this
default can be overridden easily by editing either the project
configuration from the build settings editor or the per-target
configuration.
When set on versions of Xcode that do not recognize the
`SWIFT_COMPILATION_MODE` setting, Xcode will include the option as a
user-defined setting, but otherwise ignore it.
9cdf4c9be4 gitlab-ci: update macOS jobs to use Xcode 14.0
5d2c2b2558 Tests: Update RunCMake.XcodeProject iOS cases for Xcode 14.0
12c6fec6b4 Xcode: Drop CMAKE_INTDIR= definition in Swift targets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7732
Previously we set `SYMROOT` to tell Xcode where to place the build
products. However, the "clean" operation in the Xcode "new build
system" expects that only Xcode creates the `SYMROOT` directory or
contents inside it. Since we create that directory, "clean" fails.
We now explicitly set `CONFIGURATION_BUILD_DIR` and `TARGET_TEMP_DIR`
instead of letting Xcode compute their values from `SYMROOT`, so we no
longer need to set the latter. Drop the now-unnecessary `SYMROOT`.
Fixes: #22550
Since commit 59a2265576 (Xcode: Use EFFECTIVE_PLATFORM_NAME reference in
ComputeOutputDir, 2011-08-12, v2.8.6~43^2~1) we can now set the build
products path using `CONFIGURATION_BUILD_DIR` unconditionally because we
compute the correct value even when using `EFFECTIVE_PLATFORM_NAME`.
This avoids relying on `SYMROOT` to locate the build products.
Issue: #22550
Refactoring in commit a2cfa2da4f (GenEx/LINK_LIBRARY: Add features for
framework support on Apple, 2022-02-10, v3.24.0-rc1~661^2) accidentally
removed a `GetParentDirectory` call. Restore it.
Fixes: #23891
An empty INSTALL_PATH will confuse Xcode, resulting in the archive
action producing archives that can not be uploaded to the App Store.
The logic to pull out a install_name_dir only applies to
SHARED_LIBRARY targets, so we can skip the setting of the
property for all other targets.
There might be cases where the INSTALL_PATH code path will also
end up setting an empty INSTALL_PATH, but it's unclear whether
this is a problem, so to keep the patch minimal the existing
code is left as is.
Fixes: #15183
correct Xcode generator Swift definitions
original code was defining GCC_PREPROCESSOR_DEFINITIONS which is valid only for C languages
add definitions to SWIFT_ACTIVE_COMPILATION_CONDITIONS when Swift language is used in the target
add test in SwiftOnly
for old Xcode (<8.0), append defines to cflags so it ends up in OTHER_SWIFT_FLAGS
Fixes: #23637
C++ modules have two variants which are of importance to CMake:
- `CXX_MODULES`: interface modules (those using `export module M;`,
`export module M:part;`, or `module M:internal_part;`)
- `CXX_MODULE_HEADER_UNITS`: importable header units
Creating C++ modules or partitions are *not* supported in any other
source listing. This is because the source files must be installed (so
their scope matters), but not part of usage requirements (what it means
for a module source to be injected into a consumer is not clear at this
moment). Due to the way `FILE_SET` works with scopes, they are a perfect
fit as long as `INTERFACE` is not allowed (which it is not).
Rename the booleans 's_ErrorOccured' and 's_FatalErrorOccured' to
's_ErrorOccurred' and 's_FatalErrorOccurred', respectively.
Rename the getters and setters to 'Get[Fatal]ErrorOccurred' and
'Set[Fatal]ErrorOccurred', and fix all uses across the codebase.
When determining a given target's object directory, also check for its
`OSX_ARCHITECTURES` before resorting to global defaults. This fixes inconsistent
object library references when:
- `CMAKE_OSX_ARCHITECTURES` is unset or singular
- but the object library's `OSX_ARCHITECTURES` property is set to multiple archs
Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given
`cmTarget`
- `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget`
- `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
We evaluate `LINK_LIBRARIES` and `INTERFACE_LINK_LIBRARIES` for two purposes:
* Constructing the link line.
* Collecting usage requirements.
We evaluate `INTERFACE_LINK_LIBRARIES` separately for each purpose in
order to support the `$<LINK_ONLY:...>` generator expression used to
express private link dependencies of a static library. Previously we
only evaluated `LINK_LIBRARIES` for linking, and used that result for
collecting usage requirements too. Therefore `$<LINK_ONLY:...>` does
not work in `LINK_LIBRARIES`.
With the introduction of `INTERFACE_LINK_LIBRARIES_DIRECT`, evaluation
of `LINK_LIBRARIES` now needs to distinguish these two cases in order to
honor link dependencies encountered through `$<LINK_ONLY:...>` without
also exposing other usage requirements through private dependencies of a
static library. Revise internal infrastructure to distinguish the two
cases when evaluating `LINK_LIBRARIES`. Make the information available
in code paths for `INTERFACE_LINK_LIBRARIES_DIRECT` and `LINK_ONLY`.
Defer actually using the information to later commits.
Issue: #22496
Since commit 61495cdaae (Fix Xcode project references to the source
tree, 2009-09-22, v2.8.0~43) we force source file references to use
relative paths from the source tree. If the source tree path is a
symbolic link inside the build tree, the relative `../` sequence
goes to the wrong place. The problem with debug breakpoints motivating
that change does not seem to occur in modern Xcode versions, so update
the logic to use a relative path only when it does not need to start
in any `../` sequence.
This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
