wasmtime / issue #13526 Reuse codegen cache in debug buil... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #13526 Reuse codegen cache in debug buil...

Wasmtime GitHub notifications bot (Jun 01 2026 at 19:22):

Background

Currently in crates/cache/src/lib.rs:233-256, the cache directory name is:

release builds: {compiler_name}-{GIT_REV}

debug builds: {compiler_name}-{GIT_REV}-{exe_mtime}

GIT_REV is either Wasmtime's git revision, or, if detecting that fails, Wasmtime's CARGO_PKG_VERSION.

This is good when working on Wasmtime, but invalidates the entire cache on every rebuild of a Wasmtime embedder.

Feature

Remove the exe mtime from the cache key when Wasmtime is built from a published release (e.g. crates.io).

Benefit

This change would make CI builds (and local debug iteration) much faster.

Implementation

I have also noticed a possible bug in crates/cache/build.rs:
The fallback to CARGO_PKG_VERSION is only triggered when git itself isn't installed.

Proposal: when git rev-parse HEAD fails to execute or exits with != 0, emit e.g. COMPILER_VERSION=$CARGO_PKG_VERSION.
This indicates Wasmtime was built from a non-git source (e.g. crates.io).

In lib.rs, when GIT_REV is set, use it as today (including exe_mtime in debug builds).
When COMPILER_VERSION is set instead, use just that.

Happy to create a PR if this is the right direction.

Alternatives

Alternatively, an API could be designed, allowing to specify the desired cache key directly when setting up the codegen cache.

Wasmtime GitHub notifications bot (Jun 01 2026 at 22:21):

alexcrichton commented on issue #13526:

Thanks for the report! This is similar to https://github.com/bytecodealliance/wasmtime/issues/6699 as well, and I actually had no idea that mtime was factored in to this. This is definitely something I'd love to see fixed myself. One downside of using git to detect a development build is that it's theoretically possible to use git dependencies to depend on Wasmtime, but I'm also happy to consider that a relatively niche case.

It's a bit unfortunate that there's no easy way to detect whether we're being built from crates.io or a git dep or a main workspace dep. In lieu of that I do agree that a git failure is the best indicator we have. While you're here and working on this though, if you're up for it I think it'd be best to throw away the current logic and replace it with:

git dep? always use sha + mtime

no git dep? never use mtime and only use cargo version

Casing this on debug_assertions causes confusing release-vs-debug behavior even when testing locally and is something I'd like to see fixed. Does that sound reasonable? I'd be happy to review a PR if so

Wasmtime GitHub notifications bot (Jun 02 2026 at 07:30):

bjorn3 commented on issue #13526:

For a git dep there would be no need for mtime, right? If anything it would break reproducibility. Mtime would only make sense if there are non-committed changes.

Wasmtime GitHub notifications bot (Jun 02 2026 at 07:56):

tomasol commented on issue #13526:

For a git dep there would be no need for mtime, right? If anything it would break reproducibility. Mtime would only make sense if there are non-committed changes.

I believe the dirty-tree check would not be reliable. build.rs is not rerun by Cargo when sources in other crates are changed, nor when .git/HEAD advances via a commit.

Wasmtime GitHub notifications bot (Jun 02 2026 at 10:04):

bjorn3 commented on issue #13526:

If it truly is a git dep, then there would be no uncommitted changes. If it is a path dep pointing to a git repo, then there may be uncommitted changes, but mtime wouldn't be reliable either as build scripts don't get rerun if the source changes unless you omit all rerun-if-unchanged directives to make cargo use a backcompat mode for rerunning build scripts.

Wasmtime GitHub notifications bot (Jun 02 2026 at 12:51):

tomasol commented on issue #13526:

One clarification: mtime is computed at runtime from current_exe(), not in build.rs. This is true now, and this proposal does not change it. The proposal only tightens the condition guarding when mtime is added. Previously it was for all debug builds. With this change, mtime is only used when git rev-parse HEAD succeeds in crates/cache/build.rs.

Wasmtime GitHub notifications bot (Jun 02 2026 at 17:49):

alexcrichton closed issue #13526:

Background

Currently in crates/cache/src/lib.rs:233-256, the cache directory name is:

release builds: {compiler_name}-{GIT_REV}

debug builds: {compiler_name}-{GIT_REV}-{exe_mtime}

GIT_REV is either Wasmtime's git revision, or, if detecting that fails, Wasmtime's CARGO_PKG_VERSION.

This is good when working on Wasmtime, but invalidates the entire cache on every rebuild of a Wasmtime embedder.

Feature

Remove the exe mtime from the cache key when Wasmtime is built from a published release (e.g. crates.io).

Benefit

This change would make CI builds (and local debug iteration) much faster.

Implementation

I have also noticed a possible bug in crates/cache/build.rs:
The fallback to CARGO_PKG_VERSION is only triggered when git itself isn't installed.

Proposal: when git rev-parse HEAD fails to execute or exits with != 0, emit e.g. COMPILER_VERSION=$CARGO_PKG_VERSION.
This indicates Wasmtime was built from a non-git source (e.g. crates.io).

In lib.rs, when GIT_REV is set, use it as today (including exe_mtime in debug builds).
When COMPILER_VERSION is set instead, use just that.

Happy to create a PR if this is the right direction.

Alternatives

Alternatively, an API could be designed, allowing to specify the desired cache key directly when setting up the codegen cache.

Last updated: Jul 29 2026 at 05:03 UTC