Don't use object libraries with Xcode

[jordan_rose]

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.

[beanz]

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]

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]

In D68430#1693964, @jordan_rose wrote:

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.

[jordan_rose]

In D68430#1693965, @beanz wrote:

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?

[jordan_rose]

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

[beanz]

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.

[jordan_rose]

Committed as rC373769.

clang/cmake/modules/AddClang.cmake

set(srcs
       )
   endif()
   if(ARG_SHARED)
     set(LIBTYPE SHARED)
   else()
     # llvm_add_library ignores BUILD_SHARED_LIBS if STATIC is explicitly set,
     # so we need to handle it here.
     if(BUILD_SHARED_LIBS)
-      set(LIBTYPE SHARED OBJECT)
+      set(LIBTYPE SHARED)
     else()
-      set(LIBTYPE STATIC OBJECT)
+      set(LIBTYPE STATIC)
+    endif()
+    if(NOT XCODE)
+      # The Xcode generator doesn't handle object libraries correctly.
+      list(APPEND LIBTYPE OBJECT)
     endif()
     set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
   if(TARGET ${name})
     target_link_libraries(${name} INTERFACE ${LLVM_COMMON_LIBS})
 

clang/tools/clang-shlib/CMakeLists.txt

 # Building libclang-cpp.so fails if LLVM_ENABLE_PIC=Off
 if (NOT LLVM_ENABLE_PIC)
   return()
 endif()
 
 get_property(clang_libs GLOBAL PROPERTY CLANG_STATIC_LIBS)
 
 foreach (lib ${clang_libs})
+  if(XCODE)
+    # Xcode doesn't support object libraries, so we have to trick it into
+    # linking the static libraries instead.
+    list(APPEND _DEPS "-force_load" ${lib})
+  else()
     list(APPEND _OBJECTS $<TARGET_OBJECTS:obj.${lib}>)
+  endif()
   list(APPEND _DEPS $<TARGET_PROPERTY:${lib},INTERFACE_LINK_LIBRARIES>)
   list(APPEND _DEPS $<TARGET_PROPERTY:${lib},LINK_LIBRARIES>)
 endforeach ()
 
 if (CLANG_LINK_CLANG_DYLIB)
   set(INSTALL_WITH_TOOLCHAIN INSTALL_WITH_TOOLCHAIN)
 endif()
 
 add_clang_library(clang-cpp
                   SHARED
                   ${INSTALL_WITH_TOOLCHAIN}
                   clang-shlib.cpp
                   ${_OBJECTS}
                   LINK_LIBS
                   ${_DEPS})