CMake Object Libraries Don't Map Reliably Into Xcode
I've been encountering various issues with Xcode's object library support. I think a lot of them could be dealt with if object libraries mapped into Xcode as library projects that are dependencies into their parents.
Right now object libraries map to Xcode by trying to intercept the .o output and build it back into a static library. This has a few issues:
- Xcode doesn't recognize .o's as anything other than temporary scratch data. This means that CMake is trying to manipulate undocumented scratch directories to intercept the .o's.
- On the parent target side, Xcode doesn't recognize .o's as valid input. This means the librarian flags are being manipulated to point to the already brittle .o files.
The way this is implemented is an extremely literal mirroring of how other environments handle object libraries, but it doesn't work at all reliably under Xcode, and I've watched it break over several Xcode versions.
The way this should work, that would be much more stable and reliable, and much less brittle:
- The object library targets should just be library targets in Xcode.
- The parent target should use Xcode's dependency manager to establish dependencies on the child libraries. This would build the child libraries into the parent target automatically using Xcode's dependency manager, which is much less brittle.
This would keep .o's (which are not really supported by the Xcode pipeline) out of the flow entirely.
I referenced the CMake object library documentation and I think this fits with how objects libraries are intended to be used. The object files generated seem to only be artifacts for the parent to incorporate, and not meant to be part of the final build output. Specifically:
CMake generates rules to compile the source files into object files but does not link archive or link them into a library file. Instead the object files may be included in other targets created by add_library or add_executable by listing the object library as a source with special syntax $<TARGET_OBJECTS:objlib>, where "objlib" is the object library name.
It does not seem like CMake supports outputting the .o's as a final product, which makes CMake itself only regards the .o's as an implementation detail. If the object files are not meant to be user facing, they could be factored out of the Xcode builds entirely.
In the meantime, we've had to stop using CMake projects that include object libraries with Xcode. They've just been to unstable. This sort of change would resolve the issues.
I've had a closed bug around this, and I have an open bug right now as well, which I'll find and link in the comments. But this would be a firm resolution to our problems.