blob: b7cd19b877f425ded4db023ea4cded90959ae9fb (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
; 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.
;
; (alias_rec install) keeps whatever `default` would otherwise resolve to
; (the package's own install artifacts -- executables, libraries, reached
; recursively through every subdirectory's own `install` alias) so this
; ADDS a requirement rather than replacing dune's own default behaviour.
;
; data/ef/lectionary.sexp added here for the identical reason (Task 4 fix
; round 1, coordinator review): `colitur day <year>` needs it at runtime
; (bin/main.ml's own [load_ef_lectionary]), and the same clean-build gap
; this file was originally written to close applied to it too -- a fresh
; `dune build` left it absent from _build/default/data/ef/, only ever
; materialised there as a side effect of test/dune's own deps.
(alias
(name default)
(deps
(alias_rec install)
data/ef/sanctoral.sexp
data/ef/adjustments.sexp
data/ef/lectionary.sexp))
|