TOOLS_PLATFORM.bash required version
Greg Troxel <[email protected]> Tue, 30 Jun 2026 06:58:17 -0400
| Newsgroups | gmane.os.netbsd.devel.packages |
|---|---|
| Message-ID | <[email protected]> |
Earlier I wrote that builds on macOS were failing because system bash was bash 3, and [some package] was written expecting newer bash, because bash 4.0 was released in 2009. bash 5.0 was released in 2019. Observation: The TOOLS_PLATFORM.foo definitions in platform/bar.mk are sort of like builtin.mk, except that they are static configured rather than search. Two questions phrased as assertions: We do not seem to have a way of encoding a minimum version of a tool, unlike builtin.mk and buildlink3.mk. We do not seem to document what USE_TOOLS+=bash means in terms of whether the package can then expect bash 4, bash 5, or some particular 5.x. I propose to document, perhaps in a comment in tools/defaults.mk, that bash as a tool will be >= 5.0. Then: It will be a bug if TOOLS_PLATFORM.bash is set and the pointed-to bash is < 5.0. It will be a buglet to be cleaned up if a Makefile hacks around TOOLS_PLATFORM.bash ending up with old bash, when bash 5 is ok. The only bash tool workarounds are devel/aceunit and net/wireguard-tools. I just gc'd the wireguard-tools one, explicitly as about mac/bash3, and will follow up with aceunit $MAINTAINER. Does anybody think we should say TOOLS_PLATFORM.bash must be >= 4.0 packages that use bash but aren't ok with 4 must patch or work around TOOLS_PLATFORM.bash being set instead? If so, rationale for why that's better than assuming 5? --- defaults.mk.~1.66.~ 2024-07-05 11:13:01.465622493 -0400 +++ defaults.mk 2026-06-30 06:44:15.606304239 -0400 @@ -53,6 +53,7 @@ TOOLS_DEFAULTS_MK= defined _TOOLS_VARNAME.awk= AWK _TOOLS_VARNAME.basename= BASENAME +# TOOLS_PLATFORM.bash must be >= 5.0. _TOOLS_VARNAME.bash= BASH _TOOLS_VARNAME.bison-yacc= YACC _TOOLS_VARNAME.byacc= YACC