Give the sdist check a build directory its cache can key on (#152)

`Verify the source distribution` hits **19 of 334** compilations. The
same
figure every run, never converging, with the cache restoring correctly
and
every call cacheable.

## Why

[#136](#136)
diagnosed it
and left it: scikit-build-core builds in a unique temporary directory
that has
no fixed relation to the one pip unpacked the archive into. Two
independent
random path components, so the sources sit somewhere different relative
to the
build directory every run and `CCACHE_BASEDIR` has nothing stable to
rewrite
against. The 19 hits are the dependencies that happen to live inside the
build
directory — 12 of Boost and 7 of spdlog.

What #136 did not reach for is scikit-build-core's own `build-dir`,
whose
default is documented as "a unique temporary directory" and which the
docs say
gives "major rebuild speedups" when made persistent.

## Why relative, specifically

The value has to be relative, and that is the whole of the fix. Measured
against scikit-build-core 1.0.3, the version this project pins:

```
(default)                 CMAKE_BINARY_DIR = /tmp/tmpzolfmuz5/build
SKBUILD_BUILD_DIR=build   CMAKE_BINARY_DIR = <source>/build
```

It is resolved against the source directory, which puts the working
directory
inside the source tree at a fixed depth. Every absolute path then
rewrites to
the same relative string from one run to the next — the sources to
`../…`, the
fetched dependencies to `../../fetched/…` — because the random element
is a
single directory name at a known position. An **absolute** build
directory
would fix nothing: the sources would still be at a random path.

## Cost and effect

The job takes 17m06s, the second-longest in the deploy run, about two
minutes
short of the critical path the Windows AMD64 wheels hold at 18m58s. So
this
buys billed minutes today rather than wall clock — the reason to do it
now is
the headroom before it becomes the job everything waits on.

It arrives as an environment variable on the step, which is the
mechanism
[#134](#134) already
chose
for this job's cache settings and its CMake defines, so `pip install
dist/*.tar.gz` stays the command a user would run. Nothing about what is
compiled, with which flags, or into what layout changes — only where the
intermediates are written — so it cannot mask the packaging defect the
job
exists to catch.

## Measuring it

Not on this run. New paths mean new keys, so the run that adopts this
misses
everything and populates; the **second** deploy after merging is the one
whose
hit rate means anything. Same pattern as the coverage flag in
rexlib#460.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: martin-s-a

.github/workflows/deploy.yml

@@ -343,6 +343,7 @@ jobs:
       - name: Install
         env:
           CMAKE_BUILD_PARALLEL_LEVEL: 4
+          SKBUILD_BUILD_DIR: build
           SKBUILD_CMAKE_DEFINE: FETCHCONTENT_BASE_DIR=${{ steps.fetched.outputs.dir }};CMAKE_C_COMPILER_LAUNCHER=ccache;CMAKE_CXX_COMPILER_LAUNCHER=ccache
         run: pip install --verbose dist/*.tar.gz
 

AGENTS.md

@@ -389,5 +389,13 @@ The source distribution names `external/rexlib/**` explicitly, because
 `git ls-files` does not report a submodule's contents and the archive would
 otherwise carry an empty directory and fail to build.
 
+The job that installs that distribution sets `SKBUILD_BUILD_DIR`, which is
+what lets its compiler cache work. scikit-build-core otherwise builds in a
+temporary directory of its own, unrelated to the one pip unpacked the archive
+into, so the sources sit at a different place relative to the build directory
+on every run and `CCACHE_BASEDIR` has nothing stable to rewrite against. The
+value has to stay relative — scikit-build-core resolves it against the source
+directory, and an absolute one would leave the sources where they were.
+
 Publishing to PyPI is wired up but disabled. Every push to `main` updates the
 `development` pre-release with its binaries.