Created attachment 250841 [details] Patch for meson Meson can use both devel/ninja and devel/samurai don't hardcode any as it may cause circular dependency with USES= ninja:samurai and our framework already handles port dependencies. Reference: https://cgit.freebsd.org/ports/tree/Mk/Uses/meson.mk#n29
Comment on attachment 250841 [details] Patch for meson Not every meson consumer uses (or should use) the USES=meson framework, so this needs to remain in some fashion.
Given that meson can utilize both and if you "circumvent" the framework you'd still need to chose one either way for the port (as build dep) I don't see why you'd need it defined?
It is a given that a ninja implementation is needed to run builds generated by meson, so it only makes sense to enforce the run dependency on a ninja implementation (chosen by user/framework) in this port. The ability to use either ninja implementation without using the framework has worked fine. AFAICT the conflict cases are squarely from those using USES=ninja (explicitly and implicitly). For those meson consumers that cannot use the framework, not even USES=ninja, this proposal only serves to make dependency tracking messier. Figure it out in USES=ninja.
(In reply to Daniel Engberg from comment #2) Lots of CI configs for FreeBSD (e.g., basu, seatd, picom, libva, libwacom, wlroots) expect the following to work: $ pkg install meson $ meson setup _build $ meson compile -C _build Without either ninja or samu installed "meson setup" would fail unless meson.build is very simple to support --backend=none.
> basu, seatd, picom, wlroots Oops, bad examples: hardcode "ninja" instead of using "meson compile", so can break if "meson" switches to "samu" a la Alpine Linux.
Hi Jan, Hmm... That'll at least in theory break if you change NINJA_DEFUALT to something else (which we support). I guess we need to create some kind of flavor / subpackage variant for run-depends.
Flavours/subpackages would be overcomplicating this. USES=ninja already BINARY_ALIASes samu as ninja; moving the symlinking to devel/samurai itself is a much simpler move (at the cost of a CONFLICTS_RUN). CI configs and other invocations outside of the ports system cannot hinge on what our framework does for our own builds, so the RUN_DEPENDS needs to remain, point blank.