[clang-shlib] Fix clang-shlib for PRIVATE dependencies

smeenai · smeenai · commit 3173c60f96c3 · 2019-07-11T21:20:38.000Z
Any static library with a PRIVATE dependency ends up with a $<LINK_ONLY:...> generator expression in its INTERFACE_LINK_LIBRARIES, which won't be evaluated by the $<TARGET_PROPERTY:...>, so we end up with an unevaluated generator expression in the generated build file and Ninja chokes on the dollar sign. Just use the static library directly for its dependencies instead of trying to propagate dependencies manually. Differential Revision: https://reviews.llvm.org/D64579 llvm-svn: 365825
diff --git a/clang/tools/clang-shlib/CMakeLists.txt b/clang/tools/clang-shlib/CMakeLists.txt
@@ -7,8 +7,35 @@ get_property(clang_libs GLOBAL PROPERTY CLANG_STATIC_LIBS)
 
 foreach (lib ${clang_libs})
   list(APPEND _OBJECTS $<TARGET_OBJECTS:obj.${lib}>)
-  list(APPEND _DEPS $<TARGET_PROPERTY:${lib},INTERFACE_LINK_LIBRARIES>)
-  list(APPEND _DEPS $<TARGET_PROPERTY:${lib},LINK_LIBRARIES>)
+  # Use the static library for its dependencies. The objects that constitute the
+  # static library will appear on the link line before the library, so it'll
+  # just be ignored, but the dependencies of the library will still be linked
+  # correctly.
+  #
+  # We could propagate the dependencies manually using the library's
+  # INTERFACE_LINK_LIBRARIES property, but that will contain $<LINK_ONLY:...>
+  # generator expressions if a static library has a private dependency, so we
+  # can't use a $<TARGET_PROPERTY:...> generator expression to get the property
+  # (since it wouldn't evaluate any generator expressions inside the property).
+  # We could use get_property and do string manipulation to manually evaluate
+  # the $<LINK_ONLY:...>, but that would miss any dependencies added after we
+  # evaluate the get_property. We could also use the LINK_LIBRARIES property
+  # instead, which should be free of any generator expressions, but that's
+  # technically incorrect (it'd most likely work fine in practice, but still).
+  #
+  # Another alternative would be to use --whole-archive or equivalent instead of
+  # using the object library at all. However, CMake reorders static libraries on
+  # the link line so that a library appears after all its dependents, which can
+  # reorder static libraries out of their --whole-archive --no-whole-archive
+  # sandwich. It's really hard to avoid that reordering while still propagating
+  # dependencies, which defeats the whole point.
+  #
+  # The ideal solution here is to bump our minimum CMake requirement to 3.12,
+  # which adds support for dependencies on object libraries. Until then, linking
+  # both the object and the static libraries seems like the least bad solution.
+  #
+  # TODO: Rework this when we bump our minimum CMake version to 3.12 or newer.
+  list(APPEND _DEPS ${lib})
 endforeach ()
 
 add_clang_library(clang_shared
