The proc-macro2 build generates dep-info files, seemingly to improve SCCACHE support. This unfortunately creates non-determinism issues in other build systems like Bazel as the build output depends on the build location.

In particular, the proc-macro2 dep-info file will include references to the current build directory:

$ cat bazel-bin/external/crate_index__proc-macro2-1.0.88/proc-macro2_bs.out_dir/proc_macro2.d 
/home/ubuntu/.cache/bazel/_bazel_ubuntu/6d065581cce7ad9076e3b8db2b3afaf0/sandbox/linux-sandbox/382/execroot/_main/bazel-out/k8-opt/bin/external/crate_index__proc-macro2-1.0.88/proc-macro2_bs.out_dir/libproc_macro2.rmeta: build/probe.rs

/home/ubuntu/.cache/bazel/_bazel_ubuntu/6d065581cce7ad9076e3b8db2b3afaf0/sandbox/linux-sandbox/382/execroot/_main/bazel-out/k8-opt/bin/external/crate_index__proc-macro2-1.0.88/proc-macro2_bs.out_dir/proc_macro2.d: build/probe.rs

build/probe.rs:

# env-dep:RUSTC_BOOTSTRAP

Note that the build directory is a temporary directory, whose filepath changes on every build, and which is deleted after the build: /home/ubuntu/.cache/bazel/_bazel_ubuntu/6d065581cce7ad9076e3b8db2b3afaf0/sandbox/linux-sandbox/382.

Cargo has workarounds to ensure that, similar to --remap-path-prefix, the dep-info can remove references to absolute path by setting CARGO_BUILD_DEP_INFO_BASEDIR to e.g. .. This won't work for proc-macro2 because it calls rustc directly.

Would it make sense to allow callers to opt-out of this? How does SCCACHE handle this?