Question

As a current Xcode project of mine has gotten larger and larger, I’ve noticed that quite often, Xcode seems to “recompile the world” when I make a change to a single non-header file from emacs. Not always, but a lot. I think it might have always been doing this, but when the project was small, I never noticed or cared. Now that the project’s fairly big, it’s absolutely killing my productivity. How the heck do I stop this?

Answer 1

(Yeah … answering my own question [https://meta.stackexchange.com/questions/17845/etiquette-for-answering-your-own-question%5D).

It took me a fair amount of tracking to nail this … but definitely worth it.

It boils down to the lock files that emacs creates to detect simultaneous edits from multiple emacs processes. These files are (invalid) symlinks from .#<filename> to <host:pid>. Xcode absolutely hates these files (so do some other tools I use … though I’m blanking on what they are right now … might even have been xcodebuild.) Xcode.app doesn’t actually raise any errors but it seems to chuck its dependence information. These lock files are not backup files: they exist when you’ve changed the contents of a file but not yet saved it, so what you get is behavior where just making a local change in an emacs buffer ends up causing a “rebuild the world” even though nothing’s been saved.

There isn’t, at this point, any way of disabling these lock files. The issue was raised on the emacs list a few months ago but died out without any resolution.

To work around the problem, you have to disable the lock files at compile time. You do the normal configure dance, then in src/config.h, after the #include for the os and machine configs, add #undef CLASH_DETECTION

I’ve filed a radar with Apple.