Re: testing things in the groff project?

[G. Branden Robinson]

Hi Marc,

At 2024-11-21T13:11:37+0100, Marc Chantreux wrote:
> On Wed, Nov 20, 2024 at 02:17:14PM -0600, G. Branden Robinson wrote:
> > Have you performed a build of groff from source since 1.22.4 was
> > released in December 2018?
> 
> I don't know when for the last time but I have to admit I didn't for
> year now.
> 
> But as I consider contributing to the project, let's fix that:
> 
> I started to read INSTALL and typed
> 
>       $ ./boostrap && ./configure
[...]
>       configure: groff's version string must start with three decimal
>       integers separated by dots.  "" does not match.
> 
> I edited the configure script manually so I can run make check

I recently became aware of this problem.  Apparently shallow (more
specifically, depth 1) Git clones are much more popular than I thought!

Instead of hacking the configure script, you can populate the
.tarball-version file.

$ echo 1.23.0.9999 > .tarball-version

See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082520> for
background.

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

> > Have you ever run "make check" from a groff build?
> 
> I did and was just ignorant of the fact I had a standardized test
> report format while reading ./test-suite.log.
> 
> I'm so happy to know that autotools can do TAP for me because many
> projects use them. It's sad that's so unknown.
> 
> thank you so much: you made my day.

Glad to hear it!  My next push should have a couple of new tests.  :)

Regards,
Branden

signature.asc
Description: PGP signature