Hi onf, 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?)
> 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.
> 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.
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
> and it even does some of this multiple times:
Autoconf has had a caching system for a long time. Maybe decades.
Let me quote a build I just did.
checking for inttypes.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for math.h... yes
checking for sys/mman.h... yes
checking for sys/param.h... yes
checking for sys/stat.h... (cached) 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.
No. gnulib will abstract it away for us.
> A much saner approach to portability is to either avoid
> platform-specific extensions as much as possible,
...where "platform-specific extensions" occasionally included
standardized features that a platform hasn't gotten around to supporting
for whatever reason.
> or provide wrappers with a uniform interface which do the right thing
> based on the target platform.
...you're describing a portability library, of which several exist. One
of them is named gnulib. groff uses it.
> 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. That doesn't necessarily mean that the libc was
written as one giant .c source file, and typically doesn't mean that.
> 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.
It's not a scenario I have spent any time exploring, since I frequently
update our Texinfo manual to try to correct errors in our documentation
and to keep it up to date with user-visible changes to the formatter.
> 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.
If a volunteer submitted a clean patch to support disabling generation
of Texinfo's output formats, I'd consider it. But I can't promise I'd
integrate it. There is some documentary material in our Texinfo manual
that is not duplicated in our man pages. The delta is smaller than
it was 7 years ago, but it's present.
> 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.
Some people find documentation important, even an essential aspect of a
software system. I'm one of them.
> 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.
> 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.
1. You must possess an understanding of Bourne/POSIX shell scripting.
2. You must be aware of some of the ways vendors have managed to screw
up their implementations of the Bourne/POSIX shell, such that
constructs that should work or be portable, don't actually. A
chapter of the GNU Autoconf manual spins you up on this.
3. You must understand the extreme rudiments of the m4 macro language.
I'm attaching the white paper (not a man page) introducing the m4
processor from the Seventh Edition Unix manual. I predict that you
will be able to readily absorb it.
In my experience, point 1 is the most difficult. The Unix shell is a
tricky and unforgiving language. It's also one of the most portable
languages that exists, if you write it with sufficient care (point 2).
> 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).
This sounds like one of the GNU manuals' dubious attempts at humor.
I won't defend it, but I also don't think it matters. You can ignore
whimsical asides in documentation, and should if you're not entertained
by them.
> 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.
Regards,
Branden
m4.pdf
Description: Adobe PDF document
signature.asc
Description: PGP signature
