Re: m4 and after (was: Yacc Shaving)

[Taylor R Campbell <campbell+netbsd-tech-pkg%mumble.net@localhost>]

> Date: 11 Mar 2024 18:41:08 -0400
> From: "Amitai Schleier" <schmonz%schmonz.com@localhost>
> 
> On 11 Mar 2024, at 10:22, Amitai Schleier wrote:
> 
> > For CLT 15.3.0.0.1.1708646388 users, I expect this to fix much of the 
> > fallout, but not all. For instance, packages with configure scripts 
> > that invoke "m4" or "yacc" (or "byacc") directly and haven't declared 
> > them in USE_TOOLS will pop up a macOS dialog prompting you to install 
> > the CLT.
> 
> Observing pkg_rr, I'm seeing that there's at least one widespread class 
> of packages that are largely missing "gm4" in USE_TOOLS: packages that 
> specify autoconf/automake/autoreconf in USE_TOOLS.

Do these packages invoke `gm4', or do they invoke `m4'?

I note there's an existing comment in tools.Darwin.mk explicitly
advising against using the platform's /usr/bin/gnumake and
/usr/bin/gm4 already, so maybe it's already a bad thing if these
packages try to use gm4 without USE_TOOLS:

# Avoid using the native gnumake and gm4.  On systems up to and including Big
# Sur, the version of GNU m4 is from 2006 and unable to build autoconf 2.70.
#
# While this could be more cleanly handled with a GM4_REQD set to a recent
# version, there is a larger problem that Big Sur does not support running
# these XCode programs through a symlink, causing the links in the .tools/bin
# directory to fail.
#
# Avoiding them completely at this time is much simpler.

> Two options for fixing this class of errors:
> 
> 1. "Explicit": edit each Makefile, commit en masse. Hope that future 
> developers remember to include "gm4" when they're supposed to.
> 
> 2. "Implicit": codify in mk/tools/autoconf.mk that anything using 
> autoconfery also effectively TOOL_DEPENDS on devel/m4. Hope that this 
> magic action at a distance saves more trouble/confusion than it causes.

As a general principle, if a package directly uses foo, it should
declare a dependency on foo, not rely on something else to
transitively pull it in -- and our infrastructure should do more to
detect these mistakes.

Maybe there's a case to be made for autoconf to imply m4 as part of
its interface but I'm inclined to say these packages should still
declare USE_TOOLS+=m4 or gm4 (according to what they use).

Perhaps we can create m4/gm4 wrappers that fail with an error message
rather than popping up an interactive dialogue box and waiting for
input, though, so it's a matter of one or two bulk builds to catch
them all.