macOS: compile Objective-C sources with clang when building with GCC#3073
Open
tomjn wants to merge 1 commit into
Open
macOS: compile Objective-C sources with clang when building with GCC#3073tomjn wants to merge 1 commit into
tomjn wants to merge 1 commit into
Conversation
GCC on macOS cannot target Apple's Objective-C runtime, so any Objective-C or Objective-C++ source (.m / .mm) fails to build (or interoperate) under a GCC toolchain. macOS platform integration in the renderer needs a small amount of such code (e.g. Metal presentation glue), so the engine otherwise has to be built entirely with AppleClang just to compile those few files. Enable the OBJC and OBJCXX languages on Apple and, when the C/C++ compiler is GCC, point them at clang. CMake selects a compiler per source language (.m -> OBJC, .mm -> OBJCXX, .c/.cpp -> C/CXX), so Objective-C sources are routed to clang automatically with no per-file or per-target handling, while the rest of the engine keeps building with GCC. CMake also links libc++ for targets containing such objects automatically. Scope: this covers Objective-C only, which keeps a clean ABI story -- clang compiles .m/.mm against libc++, and these sources must expose an extern "C" boundary so no C++ standard-library type crosses to the engine's libstdc++ side. C++ that must be compiled with clang is intentionally out of scope: it would require clang to use libstdc++ for ABI compatibility, which macOS does not ship; such code should instead be isolated behind a C boundary. No functional change on non-Apple platforms, and no change when already building with AppleClang (the languages are simply enabled).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
On macOS, enable the
OBJC/OBJCXXlanguages and — when the C/C++ compiler is GCC — route Objective-C / Objective-C++ (.m/.mm) sources to clang, while the rest of the engine keeps building with GCC.Why
GCC on macOS cannot target Apple's Objective-C runtime, so any
.m/.mmsource fails to build (or interoperate) under a GCC toolchain. macOS platform integration in the renderer needs a small amount of Objective-C (e.g. Metal presentation glue), so today the only way to compile those few files is to build the entire engine with AppleClang.This lets the engine stay on GCC for everything except the handful of Objective-C files. CMake selects a compiler per source language (
.m→OBJC,.mm→OBJCXX,.c/.cpp→C/CXX), so Objective-C sources are routed to clang automatically — no per-file or per-target handling. CMake also linkslibc++for targets containing those objects automatically.This is deliberately a standalone, atomic change so that both in-flight macOS renderer efforts (the Mesa/Zink path #2991 and the EGL path #3060 — each of which adds a single
.mm) can build on a shared, gcc-primary foundation instead of carrying their own toolchain plumbing.Scope / ABI note
Objective-C only. clang compiles
.m/.mmagainst libc++, so these sources must expose anextern "C"boundary — no C++ standard-library type may cross to the engine's libstdc++ side. C++ that must be compiled with clang is intentionally out of scope: that would need clang to use libstdc++ for ABI compatibility, which macOS does not ship; such code should instead be isolated behind a C boundary.Testing
enable_language(OBJC/OBJCXX)test-compiles Objective-C with clang during configure); normal GCC targets (e.g.fmt) build unaffected.main.cpp+plain.cpp+objc.mmcompiles the.cppfiles withg++andobjc.mmwithclang++ -x objective-c++, links (CMake auto-adds-lc++), and runs correctly.AI usage disclosure
Designed and drafted with AI assistance (Claude Code); reviewed and build/PoC-verified by a human.