Windows: cover libstore in CI, and let it build content-addressed derivations

[awsmadi]

Windows had no libstore test coverage at all, and the Windows derivation builder refused any output whose final path was not known before the build. This wires libstore into the Windows CI job, fixes what that exposed, and moves the shared part of the builder's output setup somewhere both platforms can use it.

Measured under Wine: nix-store-tests goes from not being built to 784 tests with 753 passing and zero failures.

Windows CI now covers libstore, and can fail

ci/gha/tests/windows.nix built only nix-util-tests, which as its own comment noted "links neither libmain nor libstore". So output checking, content-addressing and fixed-output derivations were all reached through platform-neutral code that nothing on Windows ever exercised.

The job also carried continue-on-error: true, so a Windows failure had never blocked a merge. Both together meant Windows could regress silently. That flag is gone, which is only reasonable because the suite is green.

One environment fix was needed to get there: the outer build exports NIX_STORE pointing at the host's POSIX store directory and Wine passes it through, so a store declared FilePathType::Native validated that value with is_absolute() and rejected it. Clearing it lets each store type use its own default. That alone took the failure count from 24 to 8.

Three pre-existing Windows defects the coverage exposed

LocalOverlayStoreConfig could not be constructed on Windows at all. upperLayer was a Setting<AbsolutePath> defaulting to the sentinel /upper-layer-must-be-set. AbsolutePath validates on construction, and a POSIX-rooted sentinel is not absolute on Windows, so the config threw before the caller's parameters were looked at. It is now Setting<std::optional<AbsolutePath>> defaulting to std::nullopt, which is what "must be set" means; the serialiser for that type already existed and the constructor already rejected the unset case, so the sentinel was never meaningfully read.

parseStorePath did not normalise on Windows. It wrapped the input in std::filesystem::path and compared parent_path(), so <storeDir>/./x, <storeDir>/y/../x and a trailing separator were rejected rather than normalised. It now canonicalises in whatever syntax the store directory itself uses: a Unix-style store dir stays Unix-style on Windows, which is what FilePathType::Unix is for and what lets a Windows client address a Unix store. Normalising natively would rewrite the separators and break the comparison instead. The comment saying these semantics were "unclear" is replaced with one stating them.

A C-API test asserted the Unix default store dir. The default store is local, hence native, so on Windows it is getProgramData()/nix/store.

Content-addressed and fixed-output derivations on Windows

WindowsDerivationBuilderImpl::startBuild had its own cut-down copy of the scratch-output loop which assumed every output was input-addressed:

if (!ia)
    throw UnimplementedError(
        "only input-addressed derivation outputs are supported on Windows, but output '%s' is not one", name);

That is what stopped content-addressed and fixed-output derivations from building there. They were refused before the build started, so the platform-neutral output checking and content-addressing in registerOutputs was unreachable for them.

The real loop lived in UnixDerivationBuilderImpl::startBuild but contains nothing POSIX — only needsHashRewrite(), makeFallbackPath(), scratchOutputs, hashPlaceholder() and redirectedOutputs. It moves to DerivationBuilderImpl::prepareScratchOutputs() with the two virtuals it needs. needsHashRewrite() keeps its true default and the chroot builder keeps its override; Windows has no chroot, so the default is correct there.

With that shared, the Windows builder also applies inputRewrites to its environment block and command line, as Unix does. Without a sandbox that substitution is the only way a Windows derivation can name its own outputs, since there is no chroot that could present them at their final paths instead.

extraFiles is still unimplemented on Windows. It needs a writeBuilderFile equivalent, and the natural one to reuse is the OsFilename-typed version from #15244, which has not landed.

The evaluator could not start on Windows

getFSSourceAccessor passed the literal "/" as its root. std::filesystem::path("/").is_absolute() is false on Windows — that path has a root directory but no root name, and is_absolute() wants both — so WindowsSourceAccessor's constructor assertion fired. EvalState reaches here through getFSSourceAccessor, so every command that evaluated anything aborted:

Assertion failed: root.empty() || root.is_absolute(), file src/libutil/posix-source-accessor.cc, line 648

An empty root is how this accessor already spells "no prefix, the paths I am given are absolute already" — WindowsSourceAccessor::makeAbsPath handles it explicitly and the assertion permits it — and it is the honest description of Windows, where paths are rooted per drive rather than under one root.

Measured with a cross-compiled nix.exe under Wine: before, nix eval --expr '1 + 1' aborted; after, it prints 2. nix --version and nix store info worked either way, since neither constructs an evaluator.

These are one bug, not five

Every fix above is the same mistake at a different site: treating a POSIX-rooted path as absolute on Windows, where is_absolute() requires a root name as well as a root directory. The overlay-store sentinel, the SSL cert path in #16383, parseStorePath, and the source accessor are all instances.

There is a sixth site, not fixed here, and it needs a decision rather than a patch — filed separately. Reading a .nix file gives path '/Z:\tmp\t.nix' does not exist, because CanonPath unconditionally prepends / while the caller hands it a native path. That one is a type confusion between virtual and native paths, and picking a fix requires deciding what SourcePath means on Windows.

Verification

• checks.x86_64-linux.pre-commit: 7/7 hooks
• native nix-store-tests 792/787 and nix-util-tests 813/811, both unchanged from before these commits
• nix-store-tests under Wine: 784 run, 753 pass, zero failures, confirmed by a forced rebuild rather than a cache hit
• x86_64-w64-mingw32 cross-compile clean