Commitf63643b6Recorded24 Aug 2026Repositorycore-channel

grim: locate wayland-scanner explicitly, and drop upstream's -Werror

Message

Two defects found by building it, both worth the comments they carry.

Naming wayland in BOTH dependencies: and build-inputs: -- the obvious way to say "I link the library and I run the scanner" -- is refused outright with package: duplicate input name: wayland, and there is no declarative way round it: only build inputs contribute a bin/ to PATH, and a dependency cannot export one either because PATH is builder-owned. foot does not hit this because it reads the scanner's absolute path out of pkg-config; grim does find_program('wayland-scanner'), which searches PATH, and produced "wayland-client found: YES / wayland-scanner found: NO" from one package one line apart. Answered with meson's own native file, fed from ${wayland} -- which interpolates precisely because wayland is a declared dependency.

And upstream sets werror=true, which this clang turns into a build failure on an unused variable in a PPM writer nothing here calls. Disabled for grim only; foot sets werror=true too and compiles clean under the same compiler, so this is one package's warning rather than a blanket concession.

Changed
 src/core/packages/capture.sgl | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++----------------
 1 file changed, 51 insertions(+), 16 deletions(-)
Diff
src/core/packages/capture.sglmodified
@@ -47,34 +47,46 @@
47
;; note on `fontconfig` in (core packages fonts) for why a
48
;; grand-dependency has to be named here.
49
dependencies: (list libpng pixman wayland wayland-protocols libffi zlib)
−50
;; `wayland` APPEARS IN BOTH LISTS, AND THAT IS NOT A MISTAKE.
+50
;; WAYLAND IS A DEPENDENCY ONLY, AND THE SCANNER IS POINTED AT
+51
;; EXPLICITLY. The obvious move -- naming `wayland` in BOTH
+52
;; `dependencies:` and `build-inputs:`, since grim needs the library
+53
;; linked and the `wayland-scanner` program run -- IS REFUSED:
54
;;
−52
;; grim needs two different things from it. The LIBRARY
−53
;; (wayland-client) is linked into the result, which is a
−54
;; `dependencies:` relationship. The PROGRAM `wayland-scanner` runs
−55
;; during the build to turn protocol XML into C, which is a
−56
;; `build-inputs:` relationship -- and only build inputs contribute
−57
;; their `bin/` to PATH. A dependency's `bin/` is not on PATH at all.
+55
;; package: duplicate input name: wayland
56
;;
−59
;; foot does not need the second declaration, because foot asks
−60
;; pkg-config for the scanner's absolute path
−61
;; (`wscanner.get_variable('wayland_scanner')`) rather than searching
−62
;; PATH. grim's `protocol/meson.build:3` does a plain
−63
;; `find_program('wayland-scanner')`, so without this it fails:
+57
;; and there is no way round it by declaration. Only build inputs put
+58
;; a `bin/` on PATH, and a dependency cannot export one either, because
+59
;; `PATH` is builder-owned and a `search-paths:` export naming it is
+60
;; refused as well.
+61
;;
+62
;; foot does not hit this: it reads the scanner's absolute path out of
+63
;; pkg-config (`wscanner.get_variable('wayland_scanner')`). grim's
+64
;; `protocol/meson.build:3` does a plain
+65
;; `find_program('wayland-scanner')`, which searches PATH:
66
;;
67
;; Run-time dependency wayland-client found: YES 1.24.0
68
;; Program wayland-scanner found: NO
69
;;
−68
;; Note the shape of that pair -- the library IS found and the program
−69
;; is not, from the same package, one line apart.
−70
build-inputs: (list meson samurai python wayland)
+70
;; The library is found and the program is not, from the same package,
+71
;; one line apart.
+72
;;
+73
;; The answer is meson's own mechanism for exactly this -- a native
+74
;; file naming the binary -- fed from `${wayland}`, which interpolates
+75
;; because wayland IS a declared dependency. No patch to grim, no
+76
;; second declaration, and the path is derived from the closure rather
+77
;; than searched for.
+78
build-inputs: (list meson samurai python)
79
phases: (list
80
(external-phase
81
kind: 'run
82
args: (list "sh" "-c"
83
(string-append
84
"set -eu\n"
−77
"meson setup build"
+85
"cat > native.ini <<'NF'\n"
+86
"[binaries]\n"
+87
"wayland-scanner = '${wayland}/bin/wayland-scanner'\n"
+88
"NF\n"
+89
"meson setup build --native-file native.ini"
90
" --prefix=${out}"
91
" --buildtype=plain"
92
" --default-library=static"
@@ -105,6 +117,29 @@
117
" -Dprefer_static=true"
118
;; JPEG output would add libjpeg for a format
119
;; nothing here reads.
+120
;; UPSTREAM'S WARNINGS-AS-ERRORS IS TURNED OFF,
+121
;; and this is a compiler-set difference rather
+122
;; than a defect in grim. grim's meson sets
+123
;; `werror=true`, and this toolchain's clang
+124
;; warns where the author's compiler did not:
+125
;;
+126
;; ../write_ppm.c:32:23: error: unused variable
+127
;; 'format' [-Werror,-Wunused-variable]
+128
;;
+129
;; The variable really is unused, in a PPM writer
+130
;; nothing in this channel calls. Distributions
+131
;; disable `werror` for exactly this reason: a
+132
;; project's warning policy is calibrated to the
+133
;; compilers its authors use, and turning a
+134
;; foreign compiler's extra warnings into build
+135
;; failures makes the package unbuildable for
+136
;; reasons unrelated to correctness.
+137
;;
+138
;; NOTE THAT FOOT DOES NOT NEED THIS. foot also
+139
;; sets `werror=true` and compiles clean under
+140
;; the same clang, so this is not a blanket
+141
;; concession -- it is one package's warning.
+142
" -Dwerror=false"
143
" -Djpeg=disabled"
144
;; man pages want scdoc.
145
" -Dman-pages=disabled\n"