Project

General

Profile

Bug #2688

ccache detection is static

Added by Szilárd Páll 6 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
build system
Target version:
Affected version - extra info:
Affected version:
Difficulty:
simple
Close

Description

The presence of ccache should re-assessed every time cmake is rerun, otherwise builds might fail.

Use case: a build tree is generated in an environment where ccache is detected, then reused to rebuild in one where ccache is missing (e.g. module not loaded, compute vs login node), the build will fail.

Associated revisions

Revision c961175c (diff)
Added by Mark Abraham 6 months ago

Disable ccache by default

There are too many use cases where build trees might be used on
different nodes where ccache might not be available, or with compilers
that it cannot support to continue to enable it by default. If the
user opts in, then the build system searches for ccache and gives a
fatal error if it is not found, or if the compiler is not supported.

The wrappers used by clang-tidy and clang-analyzer do not work
with ccache, so those configurations issue a fatal error if
ccache is enabled.

Made various minor aspects conform to style for naming cache
variables, use of endif(), etc.

Refs #2688

Change-Id: I55c8d4a8a07ada704c49d4f99c1557a7ab97f353

History

#1 Updated by Eric Irrgang 6 months ago

  • Difficulty simple added
  • Difficulty deleted (uncategorized)

Isn't this how CMake find_package generally works? The module not loaded shouldn't be a problem in module systems that just manipulate $PATH, but the separate configure and build systems definitely sounds like an issue. What is the preferred GROMACS way to handle that for compilers or other dependencies?

Maybe after the find_package, there should be an additional "Check that ccache works..." check? It does seem like a more graceful failure could be a minimal change.

A note to anyone choosing to tackle this one: Note the request for logic to make sure that ccache detection is quiet after the first CMake invocation.

#2 Updated by Erik Lindahl 6 months ago

Agree with Eric. CMake explicitly warns when you rerun and there's a cache that might have been generated on another system, and tells you it might be a good idea to erase the cache first. The caching and settings are complex enough as it is, so we don't want to start adding CMake code to all our modules to auto-rerun some configuration checks in those cases.

However, it can become a problem when an average user who has no idea about or interest in cache gets it enabled by default, and then it leads to this type of problem when they just continue their work on another node. As I mention in https://gerrit.gromacs.org/#/c/8609/, I think we should solve this by not having ccache enabled by default.

#3 Updated by Mark Abraham 6 months ago

Eric Irrgang wrote:

Isn't this how CMake find_package generally works? The module not loaded shouldn't be a problem in module systems that just manipulate $PATH,

This is a similar problem - cmake inspects the system and records the location of executables and libraries, etc. That won't necessarily work on other nodes. In particular, a ccache build needs to find the ccache executable or nothing can build.

but the separate configure and build systems definitely sounds like an issue. What is the preferred GROMACS way to handle that for compilers or other dependencies?

Off by default is the safest path. It's a great tool for devs, saves me a lot of time (thanks!) but clearly we didn't think through the use cases more complex than "I'm always developing on my own machine."

Maybe after the find_package, there should be an additional "Check that ccache works..." check? It does seem like a more graceful failure could be a minimal change.

It's not that simple, because what compiler wrapper to call has to propagate into all the Makefiles. If ccache isn't found, then the whole build has to be remade anyway.

#4 Updated by Gerrit Code Review Bot 6 months ago

Gerrit received a related patchset '5' for Issue #2688.
Uploader: Mark Abraham ()
Change-Id: gromacs~release-2019~I55c8d4a8a07ada704c49d4f99c1557a7ab97f353
Gerrit URL: https://gerrit.gromacs.org/8609

#5 Updated by Mark Abraham 5 months ago

  • Status changed from New to Resolved
  • Target version changed from 2019 to 2019-beta3

My patch means that this issue only arises for devs who opt in for using ccache

#6 Updated by Mark Abraham 5 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF