Problem
PTCACHE can be overridden to point at an external or shared volume, but the Pluto project code/script cache path is currently namespaced only by compiler version, optional target-CPU setting, and module path. It does not include the target OS, architecture, or LLVM target triple.
Consequently, the same cache directory can be reused by Linux, Windows, and macOS hosts even though their LLVM modules and object files target different triples and object formats. The default native CPU setting also has no cache-path segment, so hosts with different native CPUs can reuse the same project cache location.
The runtime-object cache is safer because its metadata hash includes runtime.GOOS, runtime.GOARCH, and compilation flags, but the project code/script cache does not have equivalent target isolation.
This is distinct from #82: that issue defines filesystem-independent, case-safe encoding of logical names; this issue isolates target-dependent artifacts.
Desired properties
- Decide and document whether an overridden PTCACHE may be shared across hosts.
- Namespace target-dependent code and script caches by a stable target identity, such as the LLVM target triple plus effective CPU and features.
- Prevent native builds from different CPU families or feature sets from aliasing.
- Keep runtime, code, and script cache target identities consistent where practical.
- Sanitize cache components without losing distinctions.
- Version or invalidate existing entries if the layout changes.
A possible layout is:
<PTCACHE>/<compiler-version>/<target-triple>/<target-cpu>/<encoded-module>/...
The exact layout should derive from the effective compilation configuration rather than host labels alone.
Regression coverage
- Different OS/architecture target identities produce different cache directories.
- Portable and native CPU configurations do not alias.
- Two different native CPU identities do not alias when sharing PTCACHE.
- Reusing a cache for the same effective target remains stable.
- Runtime and project cache metadata cover every setting that affects emitted artifacts.
Problem
PTCACHE can be overridden to point at an external or shared volume, but the Pluto project code/script cache path is currently namespaced only by compiler version, optional target-CPU setting, and module path. It does not include the target OS, architecture, or LLVM target triple.
Consequently, the same cache directory can be reused by Linux, Windows, and macOS hosts even though their LLVM modules and object files target different triples and object formats. The default native CPU setting also has no cache-path segment, so hosts with different native CPUs can reuse the same project cache location.
The runtime-object cache is safer because its metadata hash includes runtime.GOOS, runtime.GOARCH, and compilation flags, but the project code/script cache does not have equivalent target isolation.
This is distinct from #82: that issue defines filesystem-independent, case-safe encoding of logical names; this issue isolates target-dependent artifacts.
Desired properties
A possible layout is:
The exact layout should derive from the effective compilation configuration rather than host labels alone.
Regression coverage