Issue
Motivation
Xcode provides the ability to manipulate whatever compiler/linker toolchain is needed, but default Xcode configuration assumes Mac SDK and adds a number of default flags that do not appear anywhere in the project itself.
If these flags could be disabled/removed, Xcode's native build system could be used to control foreign compilers/toolchains such as xtensa-elf-gcc and surrounding tools, while gaining the benefit of Xcode's code highlighting and clang's analytics. This would be a strongly preferable option to the external makefile option that Xcode supports directly, which does not integrate particularly nicely with the rest of Xcode.
Motivation TL;DR
If Xcode's default flags could be disabled, Xcode could directly support compiling code for the ESP8266 (using CC=xtensa-elf-gcc).
The default flags (which assume Mac OS) are not supported by xtensa-elf-gcc and prevent its use.
The flags are the only reason this does not work.
Example
The most basic compilation produces a clang command with these flags:
-x c
-arch x86_64
-fmessage-length=0
-fdiagnostics-show-note-include-stack
-fmacro-backtrace-limit=0
-std=gnu99
-Wno-trigraphs
-fpascal-strings
-O0
-fno-common
-Wno-missing-field-initializers
-Wno-missing-prototypes
-Werror=return-type
-Wdocumentation
-Wunreachable-code
-Werror=deprecated-objc-isa-usage
-Werror=objc-root-class
-Wno-missing-braces
-Wparentheses
-Wswitch
-Wunused-function
-Wno-unused-label
-Wno-unused-parameter
-Wunused-variable
-Wunused-value
-Wempty-body
-Wconditional-uninitialized
-Wno-unknown-pragmas
-Wno-shadow
-Wno-four-char-constants
-Wno-conversion
-Wconstant-conversion
-Wint-conversion
-Wbool-conversion
-Wenum-conversion
-Wshorten-64-to-32
-Wpointer-sign
-Wno-newline-eof
-DDEBUG=1
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-fasm-blocks
-fstrict-aliasing
-Wdeprecated-declarations
-mmacosx-version-min=10.12
-g
-Wno-sign-conversion
-Winfinite-recursion
-iquote [generated-files.hmap]
-I[own-target-headers.hmap]
-I[all-target-headers.hmap]
-iquote [project-headers.hmap]
-I[Build/Products/Debug/include]
-I[Build/Intermediates/libESP8266.build/Debug/libESP8266.build/DerivedSources/x86_64]
-I[Build/Intermediates/libESP8266.build/Debug/libESP8266.build/DerivedSources]
-F[Build/Products/Debug]
-MMD
-MT dependencies
-MF [Build/Intermediates/libESP8266.build/Debug/libESP8266.build/Objects-normal/x86_64/main.d]
--serialize-diagnostics [Build/Intermediates/libESP8266.build/Debug/libESP8266.build/Objects-normal/x86_64/main.dia]
-c /Users/asher/Projects/Arduino/libESP8266/main.c
-o [main.o]
Obviously a few of these are more or less necessary (-c, -o, the various -Is, etc.) but most ought to be totally optional.
The Question
So where are they coming from? I've tried editing the basic template, and even after reducing all Mac related aspects, the result is the same. Are they added programmatically somewhere? If so, it is (presumably) in DevToolsCore or IDEFoundation?
Solution
There is an answer, but it's not a convenient one.
Xcode build implementation can be found at:
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin
The core definition appears to be assembled from .xcspec files in various plugins that can be found in:
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins
In particular, for clang and ld, check out:
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/Clang\ LLVM\ 1.0.xcplugin/Contents/Resources/Clang\ LLVM\ 1.0.xcspec
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/Ld.xcspec
Depending what you are looking for, you may have to dig. If you're looking for a specific build setting, find it in the Xcode build settings inspector and then search text contents for the corresponding variable name.
Theoretically the .xcspec files allow bundle identifiers and inheritance descriptions to assemble whatever build results you want. As far as I know, these details are not well documented / not documented at all.
Since Apple has restricted Xcode plugins to Apple only, it may not be possible to extend the build definition in a sensible way at the user level. It is possible to modify the default system, but then you end up with only the modified version.
Perhaps others have figured out or will later figure out more about how to take advantage of this setup, in which case I will update the answer to reflect our best knowledge.
Answered By - Asher