Use fastcache-cc for our own build when a daemon is running - #46
Merged
Conversation
Our own build gated the fastcache-cc launcher on FASTCACHE_ADDR being exported, so it was never picked up by default and we dogfooded ccache instead. 0.1.0 listens on 127.0.0.1:6674 out of the box and the installers register a service that starts it at login, so the address no longer needs saying. Default to that port, and make the choice conditional on a daemon actually answering: configure compiles one tiny translation unit through the launcher with FASTCACHE_VERBOSE=1 and accepts only a reported HIT/MISS. That costs about 0.1s, and it matters because the launcher never fails a build — pointed at a dead daemon it just runs the real compiler, leaving every translation unit to pay a failed connect with precompiled headers disabled for nothing and ccache passed over. Any other outcome — connect failed, a wrong service on the port, a version mismatch — falls through to sccache or ccache with the reason printed. The candidate table gains _check and _detail columns so the probe and the address in the status line stay data rows rather than branches, and the environment fastcache-cc is configured with is defined once, so the probe cannot vouch for a configuration the build does not use. A launcher already sitting in the CMake cache now says so and points at --fresh, which is otherwise an invisible reason for the selection never to run. Signed-off-by: Christian Parpart <christian@parpart.family>
FASTCACHE_ADDR has always overridden the default — the environment supplies the initial value and 127.0.0.1:6674 only fills in when it is unset — but pointing it at a remote daemon exposed two rough edges. FASTCACHE_TIMEOUT_MS bounds the launcher's send and recv, not its connect(), so an address that drops packets rather than refusing them — a firewall, a downed VPN, a host that is simply gone — leaves the probe waiting out the kernel's TCP connect timeout: 2m30s measured on macOS, paid on every configure. Give the probe its own ten-second cap, generous for a daemon that answers anywhere on a LAN and bounded for one that never will. Worth noting that a build pays that same unbounded connect once per translation unit, which the launcher itself should probably bound. The fall-back line said only "Not using fastcache-cc: connect failed", which is no help at all once the address can be somewhere other than localhost. Render the launcher and its address the same way whether the row won or was passed over, so both lines name where it pointed. Signed-off-by: Christian Parpart <christian@parpart.family>
The address is a cache entry, so ordinary CMake semantics froze it at whatever the first configure saw: exporting FASTCACHE_ADDR to reach a remote daemon did nothing to a build tree that already existed, and only -DFASTCACHE_ADDR= or a wipe would move it. That is a poor fit for an address whose whole point is to be pointed elsewhere. Record what the environment presented, and what this module last applied, in two internal cache entries. A change to the environment then retargets the entry on the next configure, while a -D passed on the current run is left alone — the two are told apart by whether the cache still holds this module's own value. The retarget needs a previous configure to compare against: on a first configure there is no bookkeeping, both tests hold vacuously, and a -DFASTCACHE_ADDR= meant to opt out would be overwritten by an address merely left in the environment. Unsetting the variable is a change like any other, and returns the tree to 127.0.0.1:6674. Signed-off-by: Christian Parpart <christian@parpart.family>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cmake/CompileCache.cmakegated its most-preferred launcher — our ownfastcache-cc— onFASTCACHE_ADDRbeing present in the environment, so out of the box it was never selected and we dogfoodedccacheinstead. 0.1.0 listens on127.0.0.1:6674and the installers register a service that starts it at login, so that address no longer needs saying.The launcher is now picked whenever a daemon actually answers there. "Actually answers" is checked rather than assumed, for the reason the launcher's own docs give:
fastcache-ccnever fails a build — pointed at a dead daemon it just runs the real compiler — so an unchecked launcher would leave every translation unit paying a failed connect, with precompiled headers disabled for nothing andccachepassed over, and nothing on screen to say so.Changes
FASTCACHE_ADDRdefaults to127.0.0.1:6674when the environment names no address. A non-empty environment value still wins,-DFASTCACHE_ADDR=host:portretargets it, and an empty value opts out.FASTCACHE_VERBOSE=1, accepted only on a reportedHIT/MISS. Measured at ~0.1 s, and it runs every configure so that starting the daemon and reconfiguring is enough.connect failed, a wrong service on the port, a version mismatch, or a probe that cannot drive the compiler all fall through tosccache/ccache, with the reason printed instead of a silent downgrade. The match is positive —HIT/MISSonly — so a future rewording of the launcher's diagnostics costs a fallback rather than a broken build._check(runtime usability hook) and_detail(extra status words) columns, keeping the probe and the address in the status line data rows rather than branches; the environmentfastcache-ccis configured with is defined once, so the probe cannot vouch for a configuration the build does not use.--fresh— an existing build tree carrying an olderccacheentry otherwise never reaches the selection logic, with no hint why.AGENT.mdanddocs/tools/fastcache-cc.mddescribe the new default and the probe.The same change is in flight for endo, which carries a copy of this module: contour-terminal/endo#174.