This is an archive of the discontinued LLVM Phabricator instance.

Don't use object libraries with Xcode
ClosedPublic

Authored by jordan_rose on Oct 3 2019, 3:12 PM.

Details

Reviewers
beanz
Summary

Undoes some of the effects of D61909 when using the Xcode CMake generator—it doesn't handle object libraries correctly at all. Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't actually test it. Should have no effect on non-Xcode generators.

Diff Detail

Event Timeline

jordan_rose created this revision.Oct 3 2019, 3:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 3 2019, 3:12 PM
beanz added a comment.Oct 3 2019, 4:48 PM

This has the side-effect of making libclang_cpp effectively empty when you build with Xcode.

What exactly does Xcode do with OBJECT libraries?

jordan_rose added a comment.EditedOct 3 2019, 6:18 PM

I'm not quite sure what it's doing. The executable targets end up trying to link against the static libraries anyway, which of course haven't been built. It's possible that this is because the LIBTYPE is both STATIC and OBJECT and if it were just OBJECT we might be better off, but I'm not sure if Xcode's IDE features will be happy with a target that doesn't actually produce a library. I can try it if you want, though.

(I did look at CMake's Xcode generator logic for OBJECT targets and it looks completely bonkers to me, as if it's still building the static library but then removing it to make sure it's not depended on or something. Even if it builds cleanly I don't trust it to do dependency analysis correctly.)

This has the side-effect of making libclang_cpp effectively empty when you build with Xcode.

I can remove that target if you want, or have it link the libraries normally.

beanz added a comment.Oct 3 2019, 6:25 PM

I'm not quite sure what it's doing. The executable targets end up trying to link against the static libraries anyway, which of course haven't been built. It's possible that this is because the LIBTYPE is both STATIC and OBJECT and if it were just OBJECT we might be better off, but I'm not sure if Xcode's IDE features will be happy with a target that doesn't actually produce a library. I can try it if you want, though.

I don't think that is necessary, it sounds like we just need to disable this functionality if Xcode is the build tool. That is unfortunate, but Xcode's build system is problematic to work with.

(I did look at CMake's Xcode generator logic for OBJECT targets and it looks completely bonkers to me, as if it's still building the static library but then removing it to make sure it's not depended on or something. Even if it builds cleanly I don't trust it to do dependency analysis correctly.)

Fair. Unfortunately Xcode's build dependencies aren't as expressive as other build systems, which causes some unfortunate limitations on what it can do.

This has the side-effect of making libclang_cpp effectively empty when you build with Xcode.

I can remove that target if you want, or have it link the libraries normally.

clang_cpp can't link the libraries "normally" because it has no unresolved symbols to force the contents of the libraries to link. I don't like it, but I think the best option is to disable clang_cpp under Xcode. You can add AND XCODE to the if on line 2 of clang/tools/clang-shlib/CMakeLists.txt, and that should do the trick.

clang_cpp can't link the libraries "normally" because it has no unresolved symbols to force the contents of the libraries to link. I don't like it, but I think the best option is to disable clang_cpp under Xcode. You can add AND XCODE to the if on line 2 of clang/tools/clang-shlib/CMakeLists.txt, and that should do the trick.

I do think it's okay to just not support that target for Xcode, but another option would be to add -all_load to the linker line, the ld64 option that just unconditionally includes all archives. What do you think?

Okay, having Xcode force-load the static libraries doesn't seem bad at all.

beanz accepted this revision.Oct 4 2019, 11:12 AM

That's fine. That said, there are things that just can't be done, or don't work well, in the Xcode and Visual Studio generators, so we have precedent for disabling functionality based on those generators.

This revision is now accepted and ready to land.Oct 4 2019, 11:12 AM
jordan_rose closed this revision.Oct 4 2019, 11:16 AM

Committed as rC373769.