My header files are using .h, and my source files are using .mm.

Yes it works fine. And after a lot of digging, I've found the problem. I think. At least I've found a problem. The file <Cocoa/Cocoa.h> includes <Foundation/Foundation.h>, which seems like a reasonable thing to do. However, clang is pulling one of our header files (which we include with "Foundation/Foundation.h") in instead of the Apple header. So it looks like I need to figure out the random way clang deals with user and system search paths (and the different ways it handles includes with <> and "") and try and figure out a solution. Thanks for the help. James

Ah thanks, that documentation showed me the way to -iquote=<path> which, if I read the documentation correctly, suggests clang has a side list of include paths that it only uses for double-quoted include directives. Now if only premake supported that... Not that I care now. Once I figured out what the problem was, I realised it's probably easiest to just rename our file, which is what I've done. Life is too short to get bogged down with things like this. :)

After some investigation, it appears these errors are coming from a postbuild step we have set up that runs dsymutil which, in turn, invokes lipo. That still doesn't explain why I'm getting errors in the first place though.

Hi Ed, Thanks for a great response. I finally found some time to go through your recommendations, and after having set up a few simple shared library projects (let's call them A and B) and a couple of simple command line applications (X and Y) in Xcode I do see that building the workspace S for scheme X and then scheme Y on the command line does indeed only build A and B once. So I guess Premake is at fault here. I see that Premake is adding project A (from the original example) not only to the workspace but also as a sub-project of all dependent projects. Could this be the cause of A being rebuilt multiple times when I build a specific project on the command line? (I think I need to switch to building the workspace and a specific scheme instead of a project, but if Premake is creating a "broken" project structure in the first place, that's not going to make much difference.)