Wasmtime GitHub notifications bot (Apr 30 2025 at 07:06): Wasmtime GitHub notifications bot (Apr 30 2025 at 07:06):adambratschikaye opened PR #10698 from adambratschikaye:abk/remove-non-deterministic-log to bytecodealliance:main:
This resolves the issue from the
eprintln!line mentioned in https://github.com/bytecodealliance/wasmtime/issues/9553.When generating a file we currently log the full path to that file which changes depending on where the build is run and can prevent cache hits in build systems like Bazel.
This change instead just prints the file name, along with a deterministic name for the parent directory (e.g.
OUT_DIRorISLE_DIR) which can be makes the log message deterministic and should still be useful for debugging.
Wasmtime GitHub notifications bot (Apr 30 2025 at 07:07):adambratschikaye requested cfallin for a review on PR #10698.
Wasmtime GitHub notifications bot (Apr 30 2025 at 07:07):adambratschikaye requested wasmtime-compiler-reviewers for a review on PR #10698.
Wasmtime GitHub notifications bot (Apr 30 2025 at 07:19):cfallin submitted PR review:
Thanks for the PR!
That said, I'm not sure how I feel about this: the original purpose of this output was to print the actual path so that someone debugging the build script steps could go read the generated file; so rewriting the printed output to use some artificial name defeats that purpose. A build tool that thinks a build-script run that prints different stderr output is different will also think that a build step that writes to a different file path is different, no? (In other words, are we really "deterministic" if Cargo is choosing a different path anyway for different runs?)
If for some reason only the diagnostic output is the issue, we could probably turn this into a
log::info!or similar. Generally though I'd rather we don't remove useful functionality to satisfy (what appears to me at the moment to be) an odd/overly-strict build tool rule.
Wasmtime GitHub notifications bot (Apr 30 2025 at 07:55):bjorn3 commented on PR #10698:
A build tool that thinks a build-script run that prints different stderr output is different will also think that a build step that writes to a different file path is different, no?
And it is even expected that build scripts output different messages depending on the target directory location. You are expected to pass an absolute path in
cargo::rustc-link-searchlines, which should be either a subdirectory ofOUT_DIRor a subdirectory of the source path of the crate itself.
Wasmtime GitHub notifications bot (May 05 2025 at 15:08):adambratschikaye closed without merge PR #10698.
Wasmtime GitHub notifications bot (May 05 2025 at 15:08):adambratschikaye commented on PR #10698:
Good points. It seems like the output was just being tracked by bazel's rules for rust crates as a means for debugging and we were able to have the rules modified so output isn't tracked by default. So this is no longer an issue.
Last updated: Dec 06 2025 at 06:05 UTC