It should be a trivial task. It’s certainly an obvious goal, and I was quite perturbed to find no clear instructions, very little discussion of it at all, and a few awkward speed-bumps on the way. But I did figure it out. So here it is, for those lucky enough to find this before they too spend a couple of frustrating hours deducing it by trial and error.
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
make -j `sysctl -n hw.logicalcpu`
FYI other configure flags of interest include:
--enable-debug-runtime (meaning debug symbols for the runtime libraries)
--enable-debug-symbols (meaning for the compiler itself)
--enable-doxygen (generate documentation)
--enable-shared (use shared libraries instead of static ones)
You now have the compiler built – you’ll find the /bin and /lib folders under “Release+Asserts” (or maybe “Debug+Asserts”, or just “Release”/”Debug”, depending on your exact configure flags).
Next, getting Xcode to use it. To begin with, grab a handy template plug-in by Gus Mueller. Unzip that and edit the Info.plist and the xcspec file contained within, to at a minimum specify the path to your build of the compiler, and perhaps change the identifiers to your own name.
Aside: Be careful if you’re using a text editor like TextEdit – in my case it thought it’d be hilarious to randomly replace normal quote characters with “smart” quotes, the presence of which will cause Xcode to refuse to load the plugin completely. Thanks, TextEdit.
Next, drop your xcplugin bundle into
/Library/Application Support/Developer/Shared/Xcode/Plug-ins/. The “Plug-ins” folder probably won’t exist yet; feel free to create it.
Note: I’m assuming you’re using Xcode 4.3 or later – i.e. the “App Store”-compatible Xcode that’s a single app, rather than the older Developer folder. If you’re using an earlier Xcode, you’ll need to put your plug-in in
Now Xcode will show (after you relaunch it) your custom compiler as an option in the build settings of any given project (see the GCC_VERSION setting, labelled “Compiler for C/C++/Objective-C”).
However, there’s a few wrinkles:
- If you try to compile a project that uses ARC, you’ll get an obnoxious linker error complaining about not being able to find libarclite_macosx.a. This is apparently some private Apple library that you cannot get the source to, let alone have bundled into the llvm repositories. Luckily, if you’re on Lion or later, you’ll find it already installed in /usr/lib/arc/. Copy that whole folder to the “lib” folder in your custom-built clang, and you’ll be good to go.
- The real-time syntax checking within Xcode will still use the built-in llvm, so any new features you use (like auto-boxing or NSNumber/NSDictionary/NSArray literals) will confuse the hell out of it. I’m searching for a solution for that (but I presume Xcode links in the relevant parts of llvm directly, possibly statically, so I doubt it’s trivial or even advisable). If it really bothers you, you can disable it by turning off “Show live issues” in the “General” tab of Xcode’s preferences.
- The Static Analyzer phase still won’t use your custom compiler. The only way I’ve found around that so far is to explicitly override CC to point to your custom compiler (which should be totally redundant; sigh). You can do that either via an xcconfig file or via the “Add Build Setting” > “Add User-Defined Setting” button at the bottom right of the Build Settings tab in the project/target inspector.
- http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June.txt (specifically, two emails from jediknil@ and rjmccall@ on June 21st, 2011 – search for “libarclite”)