[clang] [cmake] Make building dylib optional

[mgorny]

Summary

Similarly to how LLVM dylib can be disabled via LLVM_BUILD_LLVM_DYLIB,
introduce CLANG_BUILD_CLANG_DYLIB to make it possible to disable
building clang's dylib. This is useful for pure testing environments
where linking huge libraries can take a lot of memory/time.

[beanz]

Please no. You don’t need to build the library. ‘check-clang’ doesn’t depend on it, so it should not impact your build and test cycles. We want it included in the ‘all’ target for every possible configuration so that it gets tested and not broken as frequently as the LLVM dylib target has in the past.

If you don’t want to link it you can avoid linking it by running the ‘check’ targets instead of building ‘all’. In general, I believe we need to reduce the number of options for configuring the LLVM build. The build system has reached a point where the number of possible configurations is so massive that the build system is fragile and becoming more challenging to modify.

[mgorny]

Sure but I want to build-test practically everything else. I wouldn't mind if this didn't basically kill my test system by resource exhaustion.

[mgorny]

Also note that I'm leaving it enabled by default, so only people explicitly opting out would not be testing it.

[beanz]

In D67585#1670420, @mgorny wrote:

Sure but I want to build-test practically everything else. I wouldn't mind if this didn't basically kill my test system by resource exhaustion

You can use the ‘LLVM_DISTRIBUTION_COMPONENTS’ option to create a build test target that includes the things you care to test.

[mgorny]

In D67585#1670422, @beanz wrote:

In D67585#1670420, @mgorny wrote:

Sure but I want to build-test practically everything else. I wouldn't mind if this didn't basically kill my test system by resource exhaustion

You can use the ‘LLVM_DISTRIBUTION_COMPONENTS’ option to create a build test target that includes the things you care to test.

This is really much more work than disabling the one component I don't need or care for, especially when I do shared lib build and therefore the additional library is entirely useless.

[beanz]

In D67585#1670433, @mgorny wrote:

This is really much more work than disabling the one component I don't need or care for, especially when I do shared lib build and therefore the additional library is entirely useless.

It is one-time effort to figure out what you "care" about, which makes me pretty unsympathetic to the argument that it is much more work. Further, your argument for building the all target is that you want to build-test things, but you have decided this library is "useless" so you don't want to build it. How many other things in tree do you deem "useless"?

Using LLVM_DISTRIBUTION_COMPONENTS is the best way (and hopefully in the future the only supported way) to make an arbitrary choice about what is meaningful to you.

I believe the fundamental direction of the build system needs to be different from what it has been in the past, and I've had conversations with other contributors that agree. My plan is to have a larger discussion at the Developer Meeting in October, and formulate a document describing the direction and guidelines for the build system. Presently the build system is growing along a trajectory that is unsustainable and actively harmful to its maintainability. My belief is that the build system should have less options, not more. In particular we should avoid options that conflict with other options creating invalid build configurations, which this patch does (see CLANG_LINK_CLANG_DYLIB). I also believe that we should not add options for each individual's preferred workflow, instead we need to coalesce around a more limited set of supported workflows. Following this direction will reduce the maintenance cost of the build system by making it easier and less risky to make changes, and it will provide a general improvement to the project by reducing the matrix of possible configurations that require distinct testing.

[mgorny]

But in that case, we should aim for consistency, i.e. remove the matching option from LLVM.

[beanz]

In D67585#1670491, @mgorny wrote:

But in that case, we should aim for consistency, i.e. remove the matching option from LLVM.

Yes! I want to do that too.

After the mono-repo transition is finalized I think we need to invest time in cleaning up the LLVM build system and removing a bunch of legacy functionality. At the same time I think we should move the system in a new architectural direction. This is why I'm targeting to have the discussions at the Developer Meeting in October, which corresponds with the mono-repo becoming the source of truth.

clang/CMakeLists.txt

 endif()
 
 set(CLANG_VENDOR_UTI "org.llvm.clang" CACHE STRING
   "Vendor-specific uti.")
 
 set(CLANG_PYTHON_BINDINGS_VERSIONS "" CACHE STRING
     "Python versions to install libclang python bindings for")
 
+set(CLANG_BUILD_CLANG_DYLIB ON CACHE BOOL
+    "Build libclang-cpp.so dynamic library")
 set(CLANG_LINK_CLANG_DYLIB ${LLVM_LINK_LLVM_DYLIB} CACHE BOOL
     "Link tools against libclang-cpp.so")
 
 if (NOT LLVM_LINK_LLVM_DYLIB AND CLANG_LINK_CLANG_DYLIB)
   message(FATAL_ERROR "Cannot set CLANG_LINK_CLANG_DYLIB=ON when "
                       "LLVM_LINK_LLVM_DYLIB=OFF")
 endif()
 

clang/tools/clang-shlib/CMakeLists.txt

 # Building libclang-cpp.so fails if LLVM_ENABLE_PIC=Off
-if (NOT LLVM_ENABLE_PIC)
+if (NOT LLVM_ENABLE_PIC OR NOT CLANG_BUILD_CLANG_DYLIB)
   return()
 endif()
 
 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>)