Hi Branden,
On Fri Nov 22, 2024 at 2:49 AM CET, G. Branden Robinson wrote:
> At 2024-11-22T01:24:20+0100, onf wrote:
> > On Thu Nov 21, 2024 at 5:47 PM CET, G. Branden Robinson wrote:
> > > I am of course thinking in particular of CMake in the last instance.
> >
> > I would disagree with you on that.
>
> It's not clear to me which claim exactly you're disagreeing with. The
> mass of CMake's documentation compared to Automake's? (Or the GNU
> Autools' tout court?)
I was disagreeing with the sentiment that to support a diverse array of
platforms, one needs to end up with something as horrible as autotools.
My understanding of CMake is that it's equally awful, but at least it
supports Windows properly if you need that sort of thing.
> > 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".
> > 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
>
> I believe gnulib is responsible for all of these. And these checks
> aren't simply testing a guaranteed truth: should they fail, gnulib
> provides a replacement header file. That means your project can still
> compile even on a geriatric or maverick system, with no changes to your
> own source code.
Fair enough.
> 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.
> > 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
> > 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
>
> 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?
> > 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.
>
> Some people find documentation important, even an essential aspect of a
> software system. I'm one of them.
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.
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.
You can take inspiration from ffmpeg, which supports at least as many
platforms as groff does, likely more. Its configure, written by hand,
actually stands true to its name:
$ ./configure -h | grep -E '^ *-' | grep -Eviw 'print|show' | wc -l
350
Yes, that's 350 flags it supports to tune its behavior.
It also has this:
Documentation options:
--disable-doc do not build documentation
--disable-htmlpages do not build HTML documentation pages
--disable-manpages do not build man documentation pages
--disable-podpages do not build POD documentation pages
--disable-txtpages do not build text documentation pages
> > I would really much rather fight with a simpler build system that's
> > completely undocumented than with auto*,
>
> 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.
> > because there I at least wouldn't
> > be up against tens of thousands of lines of m4 bs nobody understands.
>
> There are indeed 3 prerequisites to writing an Autoconf macro.
> [...]
I wasn't talking about writing another autoconf macro (god forbid!),
I was talking about figuring out how to manually disable the texinfo
prerequisite. I overestimated the size of autotools' source files,
though; the m4 files used by gnulib unintentionally fell into the
estimate too.
> > 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.
>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.
I'm not saying it's always the case, but sometimes people really use
horrible software for no apparent reason other than inertia.
~ onf
