Files
fruix/docs/reports/phase1-guix-which-phase-runner.md

158 lines
5.1 KiB
Markdown

# Phase 1.2 follow-up: second Scheme-driven GNU package build validated with GNU which
Date: 2026-04-01
## Summary
This step extends the Scheme-driven FreeBSD validation from GNU Hello to a second small GNU/autotools package: GNU which.
Added files:
- `tests/native-build/gnu-which-guix-phase-runner.scm`
- `tests/native-build/run-gnu-which-guix-phase-runner.sh`
Like the earlier GNU Hello phase-runner, this harness uses a fixed local Guile build plus Guix's builder-side `(guix build gnu-build-system)` code to execute a subset of `%standard-phases` on FreeBSD.
## Source identity
The source of truth was the current Guix package definition in `~/repos/guix/gnu/packages/base.scm`:
- package: `which`
- version: `2.21`
- Guix nix-base32: `1bgafvy3ypbhhfznwjv1lxmd6mci3x1byilnnkc7gcr486wlb8pl`
Translated and verified SHA256:
```text
f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad
```
## Verification command
```sh
METADATA_OUT=/tmp/gnu-which-guix-metadata.txt \
./tests/native-build/run-gnu-which-guix-phase-runner.sh
```
The harness used the previously validated fixed local Guile build:
```text
/tmp/guile-freebsd-validate-install/bin/guile
```
## Guix builder phases exercised
The harness ran this subset of `(guix build gnu-build-system)` `%standard-phases`:
- `set-SOURCE-DATE-EPOCH`
- `unpack`
- `configure`
- `build`
- `check`
- `install`
## Result
The Scheme-driven GNU which build succeeded on `FreeBSD 15.0-STABLE` amd64.
Observed outcomes:
- source fetch: success
- source hash verification: success
- `configure`: success
- `build`: success
- `check`: success
- `install`: success
- runtime execution: success
The installed binary was executed as:
```sh
PATH=/bin:/usr/bin ./which sh
```
Observed output:
```text
/bin/sh
```
## Notable findings
### 1. The Scheme-driven phase-runner pattern is not limited to GNU Hello
This confirms that the earlier GNU Hello success was not a one-off. A second small GNU/autotools package also builds successfully on FreeBSD when driven by Guix's builder-side GNU build logic.
### 2. GNU which did not emit a `test-suite.log`, but `check` still succeeded
The `check` phase completed successfully, but this package did not leave behind a `test-suite.log` or `testsuite.log` file.
That is a useful reminder for future FreeBSD validation harnesses: passing `make check` cannot always be summarized by the presence of Automake-style test log files.
### 3. Guix's default `--enable-fast-install` configure flag is not universally recognized
During `configure`, GNU which reported:
```text
configure: WARNING: unrecognized options: --enable-fast-install
```
The build still succeeded. This is a small but useful data point for later FreeBSD/Guix compatibility work: some packages tolerate Guix's standard configure flag set while emitting non-fatal warnings.
### 4. Older GNU package code triggers modern clang warnings on FreeBSD
GNU which built successfully, but the build emitted several warnings about deprecated non-prototype C function declarations/definitions.
These warnings did not prevent the build, but they are good evidence that older GNU packages may need warning-tolerance assumptions when validated with modern FreeBSD clang toolchains.
### 5. Runtime linkage again matched a minimal store-like output profile
The resulting `which` binary linked against:
- `libc.so.7`
- `libsys.so.7`
That matches the store-like GNU Hello Scheme-runner result more closely than the earlier `/usr/local`-staged native shell GNU Hello build.
## Additional metadata captured
The harness recorded:
- verified source hash
- selected Guix phase list
- host triplet
- runtime dependencies
- executed command and expected output
- confirmation that the `check` phase passed
The host triplet recorded was:
```text
x86_64-unknown-freebsd15.0
```
Because this source tree did not ship an obvious `config.guess`, the harness fell back to `cc -dumpmachine` for host-triplet metadata.
## What this step demonstrates
This step strengthens Phase 1.2 in two ways:
1. it validates a second GNU/autotools package using Guix builder-side Scheme phases on FreeBSD
2. it reveals a few practical compatibility details already visible at this stage:
- optional absence of Automake-style test logs
- non-fatal `--enable-fast-install` warnings
- clang warnings in older GNU source
## Current implication for the porting effort
With both GNU Hello and GNU which validated through Scheme-driven builder-side Guix phases, the project now has evidence that FreeBSD can already support a narrow but real subset of `gnu-build-system` execution, provided the locally fixed Guile build is used.
That still falls short of a true package/derivation/store-daemon build, but it further reduces uncertainty around builder-side phase execution itself.
## Recommended next step
The next useful step is likely one of:
1. document the concrete remaining gap between these phase-runner prototypes and a real Guix package/derivation build on FreeBSD, or
2. choose a slightly more demanding GNU package with non-trivial inputs to see where builder-side execution first starts needing FreeBSD-specific adaptation