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

[G. Branden Robinson]

Hi onf,

At 2024-11-22T15:55:33+0100, onf wrote:
> My understanding of CMake is that it's equally awful, but at least it
> supports Windows properly if you need that sort of thing.

groff builds for Cygwin and MSYS2 right now, without patches as far as I
know.  If by "supports Windows properly" you mean "without a POSIX
layer", my understanding is that groff used to build on MS-DOS, but no
one's made the attempt in a long time.  I think it'd be neat to have it
running on FreeDOS.

Microsoft's offered a variety of POSIX compatibility layers over the
years; they switch them out at intervals.  I suppose that helps to
create the impression that the Windows API is more stable than that
horrible Unixy stuff over which they exercise insufficient control.

At any rate, if someone has patches to support a Windows-native groff
build, I'm happy to give them serious consideration.

> > > 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,
> >
> > The funny thing about guarantees is how often vendors fail, whether
> > through incompetence or a decision to "clear away dead weight" in
> > favor of some "bold new initiative", to back them up in fact.
> 
> Perhaps, but given that the stuff it checks for has been mandated
> since POSIX.1-2001, you could hardly make the case that such a
> platform is a "POSIX platform not several decades out of date".

AIX, HP-UX 11, and Solaris 10 are still out there.  AT&T troff is still
on them, as far as I know, and a big part of groff's mission is to be a
replacement for AT&T troff anywhere someone might want one.

> > We still support (the very old) Solaris 10, for example:
> >
> > checking for sys/time.h... yes
> > checking for stdbool.h... yes
> > checking for stdckdint.h... no
> > checking for sys/wait.h... yes
> > checking for crtdefs.h... no
> > checking for wctype.h... yes
> 
> I am not sure what this quote is supposed to illustrate. Neither of
> the two missing header files are standardized by POSIX as far as I can
> tell.  My Linux system doesn't have them either and a web search
> suggests they are something Windows-specific.

stdckdint.h is new to C23.[1]  Very long in coming, but its availability
made it pretty easy to adopt saturating arithmetic in GNU troff,
something I was keen to do.

> > > and it even does some of this multiple times:
> >
> > Autoconf has had a caching system for a long time.  Maybe decades.
> > [...]
> 
> Well, the checks I quoted apparently didn't use caching. I checked the
> output again and other ones are being cached, but the ones I quoted
> aren't.
>   $ autoconf --version | head -n 1
>   autoconf (GNU Autoconf) 2.71
>   $ automake --version | head -n 1
>   automake (GNU automake) 1.16.5

Were you quoting a groff build or some other project's?

> > Yes, it's big.  It's a compiled object (in the mundane sense, not in
> > the CS sense of "machine translation between languages").  A
> > standard C library is big, too.
> 
> Are you seriously comparing those two?

Yes.  There's nothing weird or conceptually difficult about aggregating
a collection of modular or even independent components into a whole that
is coherent for transport or execution; see ar(1) and tar(1) for
instance.  The "configure" script that Autoconf generates is an assembly
of macro-processed units for the user's convenience.  But it is not the
"preferred form for modification", as the GPL text puts it, just as a
".a" file is not the preferred means of hacking on a static library (and
would not be even if it had it not been translated into machine
language).

> As Dave Kemper noted, the fact that documentation is important doesn't
> mean its presence should be a prerequisite to being able to compile
> the software itself. One can obtain documentation by other means; it
> doesn't need to be compiled in one go with the software.

This isn't a hill I'm trying to fight on; the issue is that no one with
a jones to support a Texinfo-independent build of the groff project has
shown up to support and _maintain_ the changes necessary to do so.

> Any reasonable build setup I've ran into which requires additional
> dependencies to generate documentation allows me, at the very least,
> to disable generating documentation. Many allow one to choose between
> building the software, the documentation, or both.

Sure.  Debian packagers often exercise such flexibility.

> > Not me.  A completely undocumented build system sounds like a
> > nightmare to me--a toy or experiment undertaken by its author,
> > possibly.
> 
> If anything seems like an experiment it's autotools to be honest.

Thomas Dickey (maintainer of ncurses and other projects) has had a
notoriously difficult relationship with the Autotools.  You might be
entertained by his page on the subject.

https://invisible-island.net/autoconf/autoconf.html

I suspect the Autotools maintainers largely absorbed some of the lessons
Thomas had to offer, but as far as I know, his projects have not
rejoined the Autoconf mainstream.  Oh well.  We're all inertial about
_something_...

> I wasn't talking about writing another autoconf macro (god forbid!),

When I finally rolled up my sleeves and did so, it was much less
difficult than I had feared.

> I was talking about figuring out how to manually disable the texinfo
> prerequisite.

I don't advise anyone to attempt this until we can officially support.
If it's done at all, it should be done correctly.

> I overestimated the size of autotools' source files, though; the m4
> files used by gnulib unintentionally fell into the estimate too.

If we audit libgroff for functions that have standardized since 1990 (or
have quasi-standardized by dint of availability in gnulib), I suspect
that the library could shrink, but gnulib's contribution to our m4
footprint might increase.

That wouldn't be bad.  Let groff developers focus on groff.  Our mission
is setting type.

> > > I am still puzzled that GNU has so many volunteers and supporters
> > > given how awfully it approaches just so many things.
> >
> > I can't, and wouldn't want to, command you to contribute to any GNU
> > project.  In my experience, people who are convinced that the grass
> > is so much greener somewhere else invariably find out that it isn't.
> > They then either pretend not to have made this discovery, or they
> > embrace a more realistic perspective.
> >
> > That goes for many aspects of life, of course, not just software.
> 
> Well, most 'somewhere else' at least don't require me to surrender
> ownership of the stuff I contribute.

If you think this is true of groff, that's false.  Here's part of the
new-maintainer-onboarding email I received in September.

>>> For a program to be GNU software does not require transferring
>>> copyright to the FSF; that is a separate question.  If you transfer
>>> the copyright to the FSF, the FSF will enforce the GPL for the
>>> program if someone violates it; if you keep the copyright,
>>> enforcement will be up to you.

I'm keenly aware that the groff home page still has a banner on it
claiming that copyright assignment is required.  It's my intention to
remove that banner after I've sorted out the copyright assignment status
of past contributions: I have to ask the GNU project how to even do
this (and that process should be documented--at all, or better than it
is).  Partly, this is a matter of finding out which groff contributors
have signed copyright assignment papers _at all_; if someone has, I
don't need to follow up to find out of if the scope of such an
assignment includes groff or not.

My spidey sense tells me that this process is going to be a
high-latency, email-heavy procedure--anything that has ever involved
lawyers in its life cycle always is, and the FSF doesn't have a lot of
paid support staff.  I have therefore decided not to undertake it before
the 1.24 release.

> From my own experience, though, sometimes the grass really IS greener
> on the other side. For instance, I have had great experience switching
> away from systemd, apt, and PulseAudio.

2 out of 3 ain't bad.  Lennart Poettering seems to have a talent for
developing 66% of a solution to a problem (based on whatever Apple did
with macOS, I reckon because this is the easiest thing in the world to
sell to management staff in the tech sector) and then losing interest
and wandering off, leaving behind a cadre of maintainer-disciples who
vociferously defend the perfection of his work while telling people that
they don't really need whatever it is that's missing.  (For a
half-throated defense of systemd, see Benno Rice's LCA 2019 talk.[2])

I probably overstate.  I'm sure there are _some_ reasonable people
working on those projects.  I've just been burned repeatedly by getting
too close to Flavor-Aid drinkers.

apt, I've never had a bad experience with.[3]  dpkg author Ian Jackson
famously characterized his "views on [it] as probably not printable" in
an interview back in the day.  I wonder if this was because Jason
Gunthorpe wrote it in C++ instead of Perl.  If Mark Shuttleworth has
done one good thing in his life, it's mailing out thousands (millions?)
of free CD-ROMs of a dpkg-based distribution at a crucial period when
wretched old, half-assed RPM threatened to become the monopoly player in
GNU/Linux-based package management.  (On the other hand, it might not
have mattered--heard much about the LSB in the past 15 years?)

I'm curious to see where approaches like Nix and GNU Mes[4] take us.
(One decades-old tradition GNU keeps vigorously alive: mediocre-to-bad
project names.)

> I'm not saying it's always the case, but sometimes people really use
> horrible software for no apparent reason other than inertia.

I'll say it before someone else does: you may be attacking the
readership of this mailing list with that observation.

Fortunately for me, I don't share that view.  groff has its oddities and
frustrations, but I don't find it "horrible" or I wouldn't work on it.
But I will complain where I see problems, and try to fix them if I think
I can.  That's how a system gets improved.

I would have retitled the Subject line of this message but couldn't
think of one better than "Potpourri", which wasn't good enough.

Regards,
Branden

[1] https://en.cppreference.com/w/c/header
[2] https://www.youtube.com/watch?v=o_AIw9bGogo

[3] Package maintainers making choices that screw the dependency graph
    every which way but loose are another matter, but I haven't had to
    cope with the fallout from that for a long time, since I quit
    running Debian unstable on my daily driver.

[4] https://www.gnu.org/software/mes/

signature.asc
Description: PGP signature