Hello, On Fri, Nov 22, 2024 at 01:35:01PM -0600, G. Branden Robinson wrote: > 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. apt is a terrible interface to a very useful and mature packaging system. which leads me to write my own tool which uses: * original apt-tools to manage packages * aptitude to query the state of a system or the available packages and repo. however I realize most of newcomers only know apt which is a terrible thing because (to me at least) the packaging system is one of the best point of debian promotion. > Lennart Poettering seems to have a talent for > developing 66% of a solution to a problem (based on whatever Apple did > with macOS Another point is "both fedora and ubuntu are the distro where all bad ideas happens first" so debian is for now the safer place for average linux users. > 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]) well … I don't go on it :) I use debian with no task selected, iproute2 and nftables (no ifupdown nor networkmanager), slim and dwm. I tried to replace systemd with sinit but it failed. I have to investigate. > an interview back in the day. I wonder if this was because Jason > Gunthorpe wrote it in C++ instead of Perl. I … that … it broke my heart ! > 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. Amen! on the other hand: we were so many to experience terrible experiences at this time that "anything but RPM" was fine (I remember I moved back to slackware before someone told me about debian). I adopted debian circa 2000 and it's my distro since then both for servers and desktops (even if I gave many other distro a chance). > 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.) Guix enters slowly in my setup as a "Vagrant + Chef + Docker made right" wanabe. I'll leave my debian desktop whenever I can leave linux to OpenBSD. To come back to autotools: i recently gave a try to https://github.com/kristapsdz/oconfigure I don't know how it compares but it's much more simple. Ingo is also a reason of my interest to groff. regards, -- Marc Chantreux Pôle CESAR (Calcul et services avancés à la recherche) Université de Strasbourg 14 rue René Descartes, BP 80010, 67084 STRASBOURG CEDEX 03.68.85.60.79
