Update: Apparently there is a supported mechanism for installing externally-provided tool chains in Xcode that I wasn't aware of. For example, one can download packages from swift.org that install alternative tool chain packages into /Library/Developer/Toolchains or ~/Library/Developer/Toolchains. Once one of those is installed, Xcode has a GUI option to switch the active tool chain.
There was a recent change to the Swift sources to include a script for building one's own custom tool chain from them.
If you view the Quick Help for that build setting (View > Utilities > Show Quick Help Inspector) or configure the build settings view to show setting names instead of titles (Editor > Show Setting Names), you'll see that that setting is GCC_VERSION
.
If you look that up in the Build Settings Reference, you find:
GCC_VERSION
Description:
Numeric identifier. Identifies the GCC version to be used to compile
the target’s source files. When the target’s “System C rule” is set to
GCC System Version (instead of a specific version number), this build
setting is not available in Run Script build phases.
Values:
Default value:
GCC system version.
Specified in:
- Project Info > Rules > “System C rule.”
- Target Info > Rules > “System C rule.”
Affects:
GCC_VERSION_IDENTIFIER.
That's actually a bit out of date. It says it's specified by fiddling with a build rule (not setting) called the "System C rule". You used to change the version there but now there's a direct build setting for it.
Anyway, this probably doesn't help you do what you want to do. I doubt there's any value you could put in there that would do something useful, let alone use a third-party compiler.
However, the explanation does have a hint. It mentions the System C build rule. You could modify the build rules on the Build Rules tab of the target configuration screen. You can find the System C rule and press the button to copy it to your target, which will let you specify a custom script to process C files (including Objective-C and C++).
Implementing such a script is non-trivial. The inputs, expected outputs, and required behavior of the script are not well documented. There are various environment variables available for the use of such a script. Some are the build settings. You'll need to translate the relevant settings into compiler options. For example, translate the CLANG_WARN_BOOL_CONVERSION
setting into the corresponding -Wbool-conversion
option.
Some of the other environment variables indicate which file you should operate on, such as INPUT_FILE_PATH
, INPUT_FILE_NAME
, etc.
You need to tell Xcode what file(s) your rule outputs. These can be based on the input environment variables/settings, such as $(OBJECT_FILE_DIR)-$(CURRENT_VARIANT)/$(CURRENT_ARCH)/$(INPUT_FILE_BASE).o
.
In general, this is just not something that Xcode makes easy.