On Thu, May 22, 2025 at 12:30:37PM -0700, Paul Eggert wrote:
> On 2025-05-22 10:42, Eric Blake wrote:
> > BSD has tried hard to make their m4 be a drop-in replacement
> > enough that autoconf will use it instead of mandating GNU m4
>
> Is this a real problem, though? I just now tried running Autoconf's
> 'configure' on FreeBSD 15, and FreeBSD 15's /usr/bin/m4 quickly failed
> Autoconf's 'configure' test because it didn't support GNU m4's -F option.
That's good to remember. I remember that when I checked years ago
that the BSD version of m4 was even further away from GNU m4 (probably
when I was more active in Autoconf, around 2008). Looking at the
FreeBSD git changelog [1], I can see various spurts of development
over time where the various BSD families have cross-pollinated their
patches, such as adding some long option support (but not --help!) and
'm4 -G' in 2023. And this despite their man page stating things like:
format(formatstring, arg1, ...)
Returns formatstring with escape sequences substituted with
arg1 and following arguments, in a way similar to
printf(3). This built-in is only available in GNU-m4 com‐
patibility mode, and the only parameters implemented are
there for autoconf compatibility: left-padding flag, an op‐
tional field width, a maximum field width, *-specified
field widths, and the %s and %c data type.
At any rate, you are right that without frozen files they are not yet
a drop-in replacement for autoconf's needs (unless they also hack
their local builds of autoconf to not use frozen files - at which
point anyone motivated enough to improve two pieces of open source
software to work with each other is entitled to do so).
[1] https://cgit.freebsd.org/src/log/usr.bin/m4
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
