Fix Workspace Debug Build on macOS 27 - #10890
Conversation
Signed-off-by: Iva Horn <iva.horn@nextcloud.com>
i2h3
added
bug
os: 🍎 macOS
github-project-automation
Bot
moved this to 🧭 Planning evaluation (don't pick)
in 💻 Desktop Clients team
i2h3
changed the title
|
/backport to stable-34.0 |
287ddb7 to
3338635
Compare
claucambra
left a comment
claucambra
left a comment
There was a problem hiding this comment.
Code changes look good to me but I have concerns with Claude's (over)commenting
|
Dismissal of this kind of knowledge is the foundation for frustration of both future maintainers and potential new contributors. Code which only works without explanation why and how is insufficient and offloads effort to contributors. I have been picking up the pieces of "the code is the documentation" often enough. |
@i2h3 At no point did I say that these comments should be eliminated. My point is that comments need to be carefully considered to take the reader into account. Comments, like code, increase cognitive load: one needs to understand them and then consider them in addition to the code they are attempting to clarify. Hence they should be as short and simple as possible. It seems to me the comments in this PR are overly long, poorly structured, and opaque; they explain more about the debugging and development process the fix went through than the actual fix in place (which is typical of LLM-generated comments). I agree that the additions to the CMake files require context to understand. I just don't think it's delivered effectively in these comments |
i2h3
moved this from 🧭 Planning evaluation (don't pick)
to 🏗️ In progress
in 💻 Desktop Clients team
The Xcode scheme drives the developer build through a legacy target with
passBuildSettingsInEnvironment, so the outer build exports its settings —
COMPILER_INDEX_STORE_ENABLE=Default among them — into Craft.sh and on down to
the xcodebuild invocations that build the Finder Sync and File Provider
extensions, which pick them up as setting overrides. INDEX_DATA_STORE_DIR is
not exported with them, and those invocations override SYMROOT without a
derived data path, so in Debug the index store is enabled with nowhere to
write and clang is handed a valueless -index-store-path. It swallows the
argument behind it, which for the Realm package is the include path carrying
realm-core's headers, and the extension fails to build on
RLMUtil.hpp:23:9: fatal error: 'realm/array.hpp' file not found
Release builds never saw this: COMPILER_INDEX_STORE_ENABLE=Default leaves the
index store off there.
Pass COMPILER_INDEX_STORE_ENABLE=NO on the xcodebuild command lines, where it
outranks the inherited environment, and drop the index store variables in
Craft.sh so a build started from the scheme sees the same environment as one
started from a terminal.
Signed-off-by: Iva Horn <iva.horn@nextcloud.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3338635 to
d92cbd3
Compare
|
github-project-automation
Bot
moved this from 🏗️ In progress
to ☑️ Done
in 💻 Desktop Clients team
2 participants
Xcode 27 does some things differently. Realm fails to build. This only shows in the Xcode Workspace of the project when the client is built through that in debug configuration. This fixes it.
PS: Probably I used caveman mode of Claude too much. 😂
Checklist
AI (if applicable)