[CMake] Remove custom ccache CMake logic

[thieta]

Summary

CMake supports CMAKE_CXX_COMPILER_LAUNCHER since CMake 3.4
so this custom CMake logic we had in LLVM can now be removed.

The only downside with this is that we can't set ccache
options from LLVM CMake, but it's arguable that this doesn't
belong in LLVM but should be done in a script calling the
build.

This was discussed in the forums here:

https://discourse.llvm.org/t/tips-for-incremental-building/67289/4?u=tobiashieta

[thieta]

We could add deprecation warning for this something like:

if(LLVM_CCACHE_BUILD)
  message(FATAL "Use CMAKE_CXX_COMPILER_LAUNCHER=ccache instead")
endi()

But it seems like we haven't really done this before for CMake options, so I skipped it in this case.

[barannikov88]

I'm afraid this change will go unnoticed by build bots. They must be updated first, and a deprecation warning could help (before removing the support).

[thieta]

Happy to do a deprecation warning or error.

I am thinking we should just error if you pass the option instead of having it around doing something still. Does that sound too annoying for the bot owners or fine?

[thieta]

Add a warning when you try to pass LLVM_CCACHE_BUILD=ON to CMake

[thieta]

Ping.

[ccotter]

Looks good to me including the cmake logic. I've been building with the launcher environment variables since I posted the Discourse post. I can't really speak to the build bot side, which doesn't look to have been updated based on the most recently build of this diff.

[phosek]

LGTM

[thieta]

Basically every bot broke with this change, so I reverted it for now and posted to discourse: https://discourse.llvm.org/t/llvm-ccache-build-is-deprecated/68431

[asb]

I think it would make sense to document CMAKE_C_COMPILER_LAUNCHER and CMAKE_CXX_COMPILER_LAUNCHER under "Frequently-used CMake variables" in CMake.rst. (Also explicitly marking this review as reopened given the commit was reverted).

[jrtc27]

llvm/CMakeLists.txt

237

FATAL_ERROR and deprecated seem at odds with each other? If it's an error then it's not just deprecated, it's straight up removed.

[mehdi_amini]

I found this option quite convenient, the motivation to remove this isn’t clear to me from the description: what’s the trade off with keeping it?

[thieta]

My motivation was that people asked to add support for new cache programs (sscache and more). And now that this is supported in upstream CMake in a nice way I think our build system is way too big and complicated to duplicate functionality that's already in upstream CMake. It's more switches to keep testing and update.

Is it a big thing? No. But in a complicated build system every little matters. IMHO.

Plus the upstream option is not that much more complicated to use.

[beanz]

I think getting rid of this option is good for us and our users in the long term.

Looking past the short-term adoption shift, having LLVM's build flows be using features of CMake that work on any CMake project lowers the LLVM-specific learning curve of new contributors. Having our current users migrate also means that current users will socialize the CMake approach rather than socializing the legacy-LLVM approach. Deleting the code from the build system means less code to support.

All of these seem worth it for some short-term migration pain.

[ccotter]

Another benefit is (and I might have been using the options incorrectly, which furthers the pointd made earlier I think) is that the recursive cmake invocations did not end up forwarding the LLVM_CCACHE_BUILD value, so only the top level build would be using ccache. The *COMPILER_LAUNCHER variable seems to get passed down correctly, although I'm sure if that's explicit or a happy coincidence.

Ok - looking at the logic, I think there is some explicit forwarding of the launcher variables, but not the LLVM_BUILD_CCACHE variable. In either case, the launcher approach is implemented better for the recursive builds.

[thieta]

@jrtc27 raises a good point - we have discussed deprecating the option but made it a hard error. Should we instead make it a soft error for now and a hard error later on?

Honestly, I was not expecting this option to be used as much as it seems like it is. So maybe it makes sense to make it a soft error to start.

Any thoughts on this so I can make the appropriate changes?

[phosek]

In D143468#4128414, @thieta wrote:

@jrtc27 raises a good point - we have discussed deprecating the option but made it a hard error. Should we instead make it a soft error for now and a hard error later on?

Honestly, I was not expecting this option to be used as much as it seems like it is. So maybe it makes sense to make it a soft error to start.

Any thoughts on this so I can make the appropriate changes?

I'd be fine starting with a warning and make it an error after the LLVM 17 branch point.

[mehdi_amini]

In D143468#4123606, @beanz wrote:

I think getting rid of this option is good for us and our users in the long term.

Looking past the short-term adoption shift, having LLVM's build flows be using features of CMake that work on any CMake project lowers the LLVM-specific learning curve of new contributors.

I don't see how it is applicable here: there is no "LLVM-specific learning" to be applied here, the generic CMake flow will "just work". However it just makes everyone's configuration more cumbersome unnecessarily. I type -DLLVM_CCACHE_BUILD=ON directly without thinking about it, similarly for -DLLVM_ENABLE_LLD=ON, I wouldn't get the alternatives right.

[mehdi_amini]

My motivation was that people asked to add support for new cache programs (sscache and more)

Seems like this could be supported trivially by having -DLLVM_CCACHE_BUILD=sscache for example?\

I think our build system is way too big and complicated to duplicate functionality that's already in upstream CMake.

I don't see this as a "duplication" right now, but as a convenient wrapper on top of the functionality provided by CMake. The code you're deleting illustrates well how non-intrusive the wrapper is actually.

llvm/CMakeLists.txt

set(LLVM_TOOL_${upper_proj}_BUILD
       ${SHOULD_ENABLE_PROJECT}
       CACHE
       BOOL "Whether to build ${upper_proj} as part of LLVM" FORCE
     )
   endforeach()
 endif()
 unset(SHOULD_ENABLE_PROJECT)
 
-# Build llvm with ccache if the package is present
-set(LLVM_CCACHE_BUILD OFF CACHE BOOL "Set to ON for a ccache enabled build")
-if(LLVM_CCACHE_BUILD)
-  find_program(CCACHE_PROGRAM ccache)
-  if(CCACHE_PROGRAM)
-    set(LLVM_CCACHE_MAXSIZE "" CACHE STRING "Size of ccache")
-    set(LLVM_CCACHE_DIR "" CACHE STRING "Directory to keep ccached data")
-    set(LLVM_CCACHE_PARAMS "CCACHE_CPP2=yes CCACHE_HASHDIR=yes"
-        CACHE STRING "Parameters to pass through to ccache")
-
-    if(NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
-      set(CCACHE_PROGRAM "${LLVM_CCACHE_PARAMS} ${CCACHE_PROGRAM}")
-      if (LLVM_CCACHE_MAXSIZE)
-        set(CCACHE_PROGRAM "CCACHE_MAXSIZE=${LLVM_CCACHE_MAXSIZE} ${CCACHE_PROGRAM}")
-      endif()
-      if (LLVM_CCACHE_DIR)
-        set(CCACHE_PROGRAM "CCACHE_DIR=${LLVM_CCACHE_DIR} ${CCACHE_PROGRAM}")
-      endif()
-      set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE_PROGRAM})
-    else()
-      if(LLVM_CCACHE_MAXSIZE OR LLVM_CCACHE_DIR OR
-         NOT LLVM_CCACHE_PARAMS MATCHES "CCACHE_CPP2=yes CCACHE_HASHDIR=yes")
-        message(FATAL_ERROR "Ccache configuration through CMake is not supported on Windows. Please use environment variables.")
-      endif()
-      # RULE_LAUNCH_COMPILE should work with Ninja but currently has issues
-      # with cmd.exe and some MSVC tools other than cl.exe
-      set(CMAKE_C_COMPILER_LAUNCHER ${CCACHE_PROGRAM})
-      set(CMAKE_CXX_COMPILER_LAUNCHER ${CCACHE_PROGRAM})
-    endif()
-  else()
-    message(FATAL_ERROR "Unable to find the program ccache. Set LLVM_CCACHE_BUILD to OFF")
-  endif()
+if(DEFINED LLVM_CCACHE_BUILD)
+  message(FATAL_ERROR "-DLLVM_CACHE_BUILD=ON is deprecated! Use to the following options instead:\n-DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache")
 endif()
 
 set(LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS "" CACHE STRING
   "Optional arguments for the native tool used in CMake --build invocations for external projects.")
 mark_as_advanced(LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS)
 
 option(LLVM_DEPENDENCY_DEBUGGING "Dependency debugging mode to verify correctly expressed library dependencies (Darwin only)" OFF)
 
 # Some features of the LLVM build may be disallowed when dependency debugging is
 # enabled. In particular you cannot use ccache because we want to force compile
 # operations to always happen.
 if(LLVM_DEPENDENCY_DEBUGGING)
   if(NOT CMAKE_HOST_APPLE)
     message(FATAL_ERROR "Dependency debugging is only currently supported on Darwin hosts.")
   endif()
-  if(LLVM_CCACHE_BUILD)
-    message(FATAL_ERROR "Cannot enable dependency debugging while using ccache.")
+  if(DEFINED CMAKE_CXX_COMPILER_LAUNCHER)
+    message(FATAL_ERROR "Cannot enable dependency debugging while using a compiler launcher like ccache.")
   endif()
 endif()
 
 option(LLVM_ENABLE_DAGISEL_COV "Debug: Prints tablegen patterns that were used for selecting" OFF)
 option(LLVM_ENABLE_GISEL_COV "Enable collection of GlobalISel rule coverage" OFF)
 if(LLVM_ENABLE_GISEL_COV)
   set(LLVM_GISEL_COV_PREFIX "${CMAKE_BINARY_DIR}/gisel-coverage-" CACHE STRING "Provide a filename prefix to collect the GlobalISel rule coverage")
 endif()

llvm/docs/CMake.rst

**LLVM_BUILD_TESTS**:BOOL
   possible to build all unit tests with the target *UnitTests*.
 
 **LLVM_BUILD_TOOLS**:BOOL
   Build LLVM tools. Defaults to ON. Targets for building each tool are generated
   in any case. You can build a tool separately by invoking its target. For
   example, you can build *llvm-as* with a Makefile-based system by executing *make
   llvm-as* at the root of your build directory.
 
-**LLVM_CCACHE_BUILD**:BOOL
-  If enabled and the ``ccache`` program is available, then LLVM will be
-  built using ``ccache`` to speed up rebuilds of LLVM and its components.
-  Defaults to OFF.  The size and location of the cache maintained
-  by ``ccache`` can be adjusted via the LLVM_CCACHE_MAXSIZE and LLVM_CCACHE_DIR
-  options, which are passed to the CCACHE_MAXSIZE and CCACHE_DIR environment
-  variables, respectively.
-
 **LLVM_CREATE_XCODE_TOOLCHAIN**:BOOL
   macOS Only: If enabled CMake will generate a target named
   'install-xcode-toolchain'. This target will create a directory at
   $CMAKE_INSTALL_PREFIX/Toolchains containing an xctoolchain directory which can
   be used to override the default system tools.
 
 **LLVM_DEFAULT_TARGET_TRIPLE**:STRING
   LLVM target to use for code generation when no target is explicitly specified.

llvm/docs/ReleaseNotes.rst

 ----------------------
 
 * Typed pointers are no longer supported. See the `opaque pointers
   <OpaquePointers.html>`__ documentation for migration instructions.
 
 Changes to building LLVM
 ------------------------
 
+* Removed ``LLVM_CCACHE_BUILD``, ``LLVM_CCACHE_MAXSIZE``, ``LLVM_CCACHE_DIR``
+  and ``LLVM_CCACHE_PARAMS`` CMake options. Upstream CMake supports setting
+  ``CMAKE_CXX_COMPILER_LAUNCHER=ccache`` since CMake 3.4 and should be used
+  instead.
+
 Changes to TableGen
 -------------------
 
 Changes to Interprocedural Optimizations
 ----------------------------------------
 
 Changes to the AArch64 Backend
 ------------------------------

mlir/utils/clang-tidy/README.md

- `build/` must be a directory with MLIR onfigured. It is highly advised to
   use `ccache` as well, as this directory will be used to rerun
   `ninja check-mlir` after every single clang-tidy fix.
 ```bash
 $ cmake ../llvm \
   -DLLVM_ENABLE_PROJECTS="mlir" \
   -DCMAKE_BUILD_TYPE=Release \
   -DLLVM_ENABLE_ASSERTIONS=ON \
   -DLLVM_TARGETS_TO_BUILD="Native;NVPTX;AMDGPU" \
-  -DLLVM_CCACHE_BUILD=ON \
+  -DCMAKE_C_COMPILER_LAUNCHER=ccache \
+  -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
   -DCMAKE_C_COMPILER=clang \
   -DCMAKE_CXX_COMPILER=clang++ \
   -DLLVM_ENABLE_LLD=ON \
   -DLLVM_BUILD_EXAMPLES=OFF \
   -DMLIR_ENABLE_BINDINGS_PYTHON=ON \
   -G Ninja
 ```
 - `mlir/` is the directory where to find the files, it can be replaced by a
   subfolder or the path to a single file.
 - `mkdir -p ~/clang-tidy-fails/` will be a directory containing the patches
   that clang-tidy produces but also fail the build.