summaryrefslogtreecommitdiff
path: root/dune
diff options
context:
space:
mode:
authorLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 01:13:53 +0200
committerLukasz Kasprzak <lukas@labunix.xyz>2026-08-12 01:13:53 +0200
commit9725195fc4a1050ded151854f6653459dacc35b0 (patch)
tree86ae7de30af42d1caa06751da6c715536f7ebc48 /dune
parent7f183c847f8b67c88ad6ea3bf2d635c5c0534651 (diff)
downloadcolitur-9725195fc4a1050ded151854f6653459dacc35b0.tar.gz
colitur-9725195fc4a1050ded151854f6653459dacc35b0.zip
build: materialise data/ef/*.sexp as part of the default build target
A genuinely clean rebuild -- rm -rf _build && dune build && dune exec colitur -- day 2026 -- failed: nothing in the default build graph asked for data/ef/sanctoral.sexp or adjustments.sexp, only test/dune's cram stanza did (its own explicit deps), so dune build alone never materialised them under _build/default/data/ef/, and colitur day (bin/main.ml's data_dir, which reads them straight off the build tree) failed to find them. dune build @runtest masked this entirely, and the test suite could not have caught it on its own: the cram stanza supplies its own deps regardless of whether anything else in the project needs them. Verified empirically that neither a plain (alias (name default) ...) in data/ef/dune nor one in bin/dune is enough on its own -- bare 'dune build' resolves to something narrower than either recursive alias propagation would suggest. A root-level dune file's default alias, explicitly depending on (alias_rec install) plus the two data files, is what a genuinely clean rebuild actually needs.
Diffstat (limited to 'dune')
-rw-r--r--dune23
1 files changed, 23 insertions, 0 deletions
diff --git a/dune b/dune
new file mode 100644
index 0000000..de5051c
--- /dev/null
+++ b/dune
@@ -0,0 +1,23 @@
+; Makes data/ef/*.sexp part of the DEFAULT build target (`dune build`, no
+; args), not only whatever individual stanzas elsewhere happen to declare as
+; their own deps. Without this, `rm -rf _build && dune build && dune exec
+; colitur -- day 2026` failed: bare `dune build` resolves to the workspace
+; root's own `default` alias, which -- absent this file -- is implicitly
+; bound to `@install` alone and never reaches data/ef/dune's own `default`
+; alias (that alias only participates in an EXPLICIT `@default`/`@dir`
+; recursive request, e.g. `dune build @default`, not in the plain no-target
+; invocation; verified empirically -- see the task report). `test/dune`'s
+; cram stanza masked this: it declares its own (deps ../data/ef/*.sexp),
+; which materialises them as a side effect of `dune build @runtest`, so the
+; test suite could not have caught this on its own -- it took a genuinely
+; clean rebuild to surface it.
+;
+; (:standard) keeps whatever `default` would otherwise resolve to (the
+; package's own install artifacts -- executables, libraries) so this ADDS a
+; requirement rather than replacing dune's own default behaviour.
+(alias
+ (name default)
+ (deps
+ (alias_rec install)
+ data/ef/sanctoral.sexp
+ data/ef/adjustments.sexp))