Re: m4 and after (was: Yacc Shaving)

["Amitai Schleier" <schmonz%schmonz.com@localhost>]

On 12 Mar 2024, at 12:27, Taylor R Campbell wrote:

> > 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'm not sure. Some clues so far, after dropping this in my mk.conf:

    .for t in m4 gm4 yacc byacc
    .  if empty(USE_TOOLS:M${t})
    TOOLS_FAIL+=${t}
    .  endif
    .endfor

- mail/vmailmgr-base does not emit any "WARNING: Please add USE_TOOLS+=" 
lines during configure.

- x11/modular-xorg-xquartz _does_ emit "WARNING: Please add 
USE_TOOLS+=gm4" (twice) during configure. If I remove m4 from USE_TOOLS, 
there's a third occurrence of that message, plus six "WARNING: Please 
add USE_TOOLS+=m4".

- vmailmgr-base does not call any m4_* functions from its configure.ac. 
modular-xorg-xquartz has 9 such calls. Hey, 9 == 3 + 6.

As we'd expect, these wrappers do seem to prevent the Command Line Tools 
install dialog from appearing. I was hoping they'd stop the build. 
Anyone know a trick to make them do that?

> 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).

The above cases start to narrow it down, but I don't yet have a good 
rule for which autoconf-using packages will need to invoke "m4" (or 
"gm4"). So neither of my proposed approaches is sensible yet.

> 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.

Yes! See above.

Once we can turn any given undeclared tool into a build breaker, we 
could enumerate all possible tools, subtract the ones declared in 
USE_TOOLS, and turn all the others into build breakers. Give the new 
check a name, default it to off, and enable by default for 
PKG_DEVELOPER=yes.