Automake (was Re: testing things in the groff project?)

[onf]

On Thu Nov 21, 2024 at 5:47 PM CET, G. Branden Robinson wrote:
> > > You can find out more about the framework groff uses for automated tests
> > > at the following link.
> > > 
> > > https://www.gnu.org/software/automake/manual/automake.html#Scripts_002dbased-Testsuites
> > 
> > I never got that far in the automake documentation because I never
> > felt the need to learn something as scarry (based on m4 is enough for
> > me to run away, I'm a coward) and ignored that autotools did so many
> > things.
>
> Automake itself doesn't, as I understand it, have much to do with
> m4--but Autoconf certainly does.
>
> I would agree that the GNU build system is intimidating.  I've come to
> the conclusion that build systems that have to cope with a diversity of
> software projects and target platforms always become complex, perhaps
> inescapably.  Of course every few years someone comes down the pike with
> a promise of a "simple", "rational" build tool that does just what you
> want and nothing you don't.
>
> It doesn't take long for the newcomer to prove just as unwieldy and
> complicated as Autotools, and typically less flexible.  And if its
> documentation is lean, that's usually because it's woefully incomplete.
> When the documentation is reasonably comprehensive, it ends up weighing
> about the same as the Autotools manuals.
>
> I am of course thinking in particular of CMake in the last instance.

I would disagree with you on that. Checking the output of ./configure
in groff's repository shows that autoconf checks for stuff that's
guaranteed to be true on any POSIX platform that's not several decades
out of date, and it even does some of this multiple times:
  checking for stdio.h... yes
  checking for stdlib.h... yes
  checking for string.h... yes
  checking for inttypes.h... yes
  checking for stdint.h... yes
  checking for strings.h... yes
  checking for sys/stat.h... yes
  checking for sys/types.h... yes
  checking for unistd.h... yes
  checking for wchar.h... yes
  ...
  checking for stdint.h... yes
  checking for inttypes.h... yes

Most of those checks are useless anyway because groff's source code has to
make some assumptions about its build environment; it's not like autoconf
can just abstract away missing string.h.

A much saner approach to portability is to either avoid platform-specific
extensions as much as possible, or provide wrappers with a uniform
interface which do the right thing based on the target platform.

If a configure script is really needed, one written by a human is always
preferrable to the autoconf one:
  $ wc -l groff/configure
  34951 groff/configure

In general, I really dislike how difficult it is to change auto*'s
behavior if it collides with one's expectations. For instance, I would
like to build groff without texinfo documentation because I don't
need it. I haven't found any documentation on groff's side on how to
do this. The 'right' way according to automake's docs is to pass the
option `no-installinfo` to AM_INIT_AUTOMAKE in configure.ac...
well, except that's forbidden at the 'gnu' strictness level:
  configure.ac:40: error: option 'no-installinfo' disallowed by GNU standards

... which also happens to be the default. So you also need to
pass the option 'foreign', which lowers its strictness level.
So, finally, it should compile, right?
  checking for makeinfo... no
  configure: error: missing 'makeinfo'
  Get the 'texinfo' package version 5.0 or newer.

......

The hacky way would be to make auto* believe makeinfo is installed...
I've spent at least half an hour on it and haven't found a way
because regardless of which checks I delete, it re-generates those
files anyway. Creating a dummy makeinfo script doesn't fool it either.

The result is that it seems impossible to build groff without installing
texinfo despite the program itself not depending on it in any way, which
is completely absurd.

I would really much rather fight with a simpler build system that's
completely undocumented than with auto*, because there I at least wouldn't
be up against tens of thousands of lines of m4 bs nobody understands.

By the way, reading up on automake's strictness levels reveals this gem:
  gnits
    Automake will check for compliance to the as-yet-unwritten Gnits standards.
    These are based on the GNU standards, but are even more detailed. Unless
    you are a Gnits standards contributor, it is recommended that you avoid
    this option until such time as the Gnits standard is published (which is
    unlikely to ever happen).

...

I am still puzzled that GNU has so many volunteers and supporters given
how awfully it approaches just so many things.

~ onf