Hi Alex, At 2026-08-23T21:30:53+0200, Alejandro Colomar wrote: > > Date: 2026-08-23 11:44:51-0500 > > From: "G. Branden Robinson" <[email protected]> > > > > [looping in groff list because Alex brought to my attention an item > > of work on the new man(7) `LS` and `LE` macros that needs to be > > done] > > At 2026-08-23T17:06:16+0200, Alejandro Colomar wrote: > > > I dislike autotools for that and other reasons. > > > > Autoconf, Automake, and Libtool, the collective "autotools", are all > > strongly distinguishable in purpose. > > I guess if you deal with them enough, you get to distinguish them. In > shadow-utils, where we have an autotools-based build system, I > consistently avoid to learn it. I leave it up to the other > maintainers and the distro maintainers to keep it working. I only > report the issues to them. To me, it'd be easier to wipe it all and > write a Makefile from scratch than learning the tools. The day I have > to maintain that, I'll probably do so. But distro maintainers don't > want that, and so they keep helping maintain it.
Sometimes success looks like that. :) > > Autoconf is a brilliant idea, very well executed. I suspect that > > many of its its detractors possess a constellation of negative > > traits: > > > > 1. They're not terribly competent at writing portable shell > > scripts; > > I believe I'm quite competent writing shell scripts. :) From what I've seen, I think you're right. :) > > > 2. they refuse to understand the very simple principle of operation > > of the m4 macro language; and > > I have the 2nd negative trait, though. Nobody has time to learn everything. But I take a dim view of refusal to learn things for bad reasons. It can be hard to judge, and for sure to know exactly what a person's reasons are, because even if they don't misrepresent those reasons to others, they might lack the self-awareness necessary to know why they don't do things. For example, when I procrastinate a task, I often find myself trying to figure out post facto why I did so, after I get around to doing it. Often, I expect that a task will be more difficult than it turns out to be. I let myself get unnecessarily daunted. But, speaking only for myself, getting the "gist" of a nearly pure macro expansion engine like m4 was extremely useful in a way that I didn't appreciate at the time, because the way I learned to think about m4 ended up helping me to understand how *roff works. *roff is a very _impure_ macro expansion engine. Lots of extra stuff piled on. :) Doug McIlroy has a lovely presentation. https://www.cs.dartmouth.edu/~doug/barem4.m4 For those who fear to read M4 even when commented, the concepts are also discussed in this Computer History Museum oral history interview. https://archive.computerhistory.org/resources/access/text/2019/11/102740539-05-01-acc.pdf > > 3. they refuse to believe that the variety of possible deployment > > environments is as wide as it is. > > I acknowledge this. However, some people refuse to believe that > hand-crafted makefiles can also handle quite different environments > too. I believe makefiles can do that just fine. It's a matter of how > much makefile code you write. I wouldn't have ventured an opinion either way; I'm confident GNU Make is up to the challenge, but less sure about POSIX Issue 8 make(1). > In the Linux man-pages project, we have 120 kB of makefiles. > > $ find share/mk/ -type f | xargs wc -c GNUmakefile | tail -n1 > 119125 total > > I believe that a set of makefiles that would handle all of the targets > of a project like groff wouldn't take much more than that. It might > be a few hundred kB. If it's well organized, it can be maintainable. I was going to venture that groff's Automake files added up to much less than that. It's less--but not "much". $ wc -c $(find -name "*.am" | grep -v gnulib | sort) 31886 ./Makefile.am 1245 ./arch/mingw/mingw.am 1295 ./arch/misc/misc.am 3554 ./contrib/chem/chem.am 1324 ./contrib/eqn2graph/eqn2graph.am 2247 ./contrib/gdiffmk/gdiffmk.am 2400 ./contrib/glilypond/glilypond.am 1583 ./contrib/gperl/gperl.am 1842 ./contrib/gpinyin/gpinyin.am 1331 ./contrib/grap2graph/grap2graph.am 4559 ./contrib/hdtbl/hdtbl.am 1046 ./contrib/install-font/install-font.am 6150 ./contrib/mm/mm.am 5966 ./contrib/mom/mom.am 1312 ./contrib/pic2graph/pic2graph.am 1281 ./contrib/rfc1345/rfc1345.am 2646 ./contrib/sboxes/sboxes.am 31579 ./doc/doc.am 2210 ./font/devX100-12/devX100-12.am 2089 ./font/devX100/devX100.am 2175 ./font/devX75-12/devX75-12.am 2056 ./font/devX75/devX75.am 1757 ./font/devascii/devascii.am 2858 ./font/devdvi/devdvi.am 2496 ./font/devhtml/devhtml.am 1781 ./font/devlatin1/devlatin1.am 1739 ./font/devlbp/devlbp.am 2956 ./font/devlj4/devlj4.am 8531 ./font/devpdf/devpdf.am 5580 ./font/devps/devps.am 2387 ./font/devutf8/devutf8.am 1047 ./font/scripts/scripts.am 1331 ./man/man.am 1290 ./src/devices/grodvi/grodvi.am 1597 ./src/devices/grohtml/grohtml.am 1357 ./src/devices/grolbp/grolbp.am 1295 ./src/devices/grolj4/grolj4.am 2232 ./src/devices/gropdf/gropdf.am 1637 ./src/devices/grops/grops.am 1589 ./src/devices/grotty/grotty.am 4372 ./src/devices/xditview/xditview.am 1508 ./src/include/include.am 1048 ./src/libs/libbib/libbib.am 987 ./src/libs/libdriver/libdriver.am 3625 ./src/libs/libgroff/libgroff.am 1150 ./src/libs/libxutil/libxutil.am 3571 ./src/preproc/eqn/eqn.am 1398 ./src/preproc/grn/grn.am 1149 ./src/preproc/html/html.am 2689 ./src/preproc/pic/pic.am 1356 ./src/preproc/preconv/preconv.am 2838 ./src/preproc/refer/refer.am 1317 ./src/preproc/soelim/soelim.am 2785 ./src/preproc/tbl/tbl.am 9555 ./src/roff/groff/groff.am 1528 ./src/roff/nroff/nroff.am 2112 ./src/roff/troff/troff.am 1227 ./src/utils/addftinfo/addftinfo.am 1686 ./src/utils/afmtodit/afmtodit.am 1758 ./src/utils/grog/grog.am 1033 ./src/utils/hpftodit/hpftodit.am 2085 ./src/utils/indxbib/indxbib.am 1109 ./src/utils/lkbib/lkbib.am 1098 ./src/utils/lookbib/lookbib.am 1443 ./src/utils/pdfmom/pdfmom.am 1200 ./src/utils/pfbtops/pfbtops.am 1027 ./src/utils/tfmtodit/tfmtodit.am 1468 ./src/utils/xtotroff/xtotroff.am 15018 ./tmac/tmac.am 228376 total 228kB is an order of magnitude higher than I'd have guessed. But I should have known better--from bitter experience I should have intuited that the "doc.am" beast alone defeats any such notion. That's always the most troublesome of our Automake scripts, because we use the groff that we build to produce further artifacts. It therefore functions in part as an acceptance test. > Because the makefile language is so simple, bugs are easy to spot and > fix, compared to autotools (possibly automake, but I can't distinguish > them enough). Apart from needing an awareness of Automake's special variable names, which employ a naming scheme that one tends to notice, I can almost always get by writing an Automake script using only "make(1) brain", which is one reason I've been such crap at actually _learning_ Automake. I more often have problems writing Automake scripts that will maintain portability between GNU Make and BSD Make, which is a constraint entirely of my own choosing. > Oh, yeah, I agree with everyone here. CMake is way worse than > autotools. autotools is the least evil of the non-pure-makefile build > systems. I'm curious to hear your opinion of meson/ninja. > > Hmm, no release since 4.4 on Halloween 2022. Yeah, they might be > > due. > > Yup, I've been pinging Paul a few times in the last years. But I gave > up last year. I don't begrudge Paul D. Smith a victory lap/vacation after the triumph of POSIX Issue 8 blessing so many GNU Make extensions. :) But each one justified itself more than adequately. This document remains useful. https://gist.github.com/Earnestly/29deee4f18346da6630ed1df760f1590 > > Yes, but the tarballs get tested in a greater diversity of > > environments. While I keep git HEAD "green"--I don't "git push" > > unless "make distcheck" runs successfully--that applies only to my > > personal development environment. groff doesn't have a CI > > infrastructure. > > > > The build system is the thing that consistently gives us the most > > pain when trying to firm up a release. So right now you are pulling > > on HEAD at its most fragile, ironically. The code quality should be > > good, _if_ you can get the build to completion. > > I'm happy to uncover those bugs; it's not a problem. I appreciate your patience. It's hard not to feel like every problem discovered in an RC reflects a maintainership failure on my part. Intellectually, I know that's not how collaborative software development works. Psychologically, I want everything I produce to be so perfect that it inspires envy. :) > Why not this?: > > .LE > .P Good idea! This slots right in with no changes at all to the man(7) package. All of mandoc(1)'s complaints are as expected. $ mandoc -T lint ATTIC/inline-compact-list.man mandoc: ATTIC/inline-compact-list.man:9:2: ERROR: skipping unknown macro: .LS itemized 1 4n mandoc: ATTIC/inline-compact-list.man:18:2: ERROR: skipping unknown macro: .LE mandoc: ATTIC/inline-compact-list.man:1:5: STYLE: lower case character in document title: TH foo mandoc: ATTIC/inline-compact-list.man:10:2: WARNING: skipping paragraph macro: PP empty (I expect the third of those ("STYLE") to go away when Ingo makes his next mandoc(1) release.) So that's one fewer problem I have to solve. Thanks! But I just found a different one to replace it. groff_man(7) says: ... Use IP without arguments to associate successive paragraphs with an existing list item; to these, inter‐ paragraph spacing applies even in compact lists. ...but that last clause is not working. I'll work on that. > You might use compactness keywords: > > .LS itemized precompact > > You could have 'precompact', 'postcompact', 'compact', and > 'noncompact' (feel free to use names that aren't so terrible). This might now not be necessary at all; people can simply use your idiom. `P` (and its synonyms `LP` and `PP`) always apply inter-paragraphing spacing even in compact lists. That's on purpose, because sometimes a document uses compact lists where an item requires multiple paragraphs, or interrupts the list with commentary. I like your idiom of sticking `P` after the `LS` and/or the `LE` calls as and where one wants inter-paragraph spacing before and/or after the (compact) list. I had designed the macros with that in mind, but had not thought of that simple way to express it. A list item per se starts with either: * an argumentful `IP` macro call (for itemized or enumerated lists); or * a `TP` macro call (for definition lists). To recap, I have two macro programming problems to solve for RC3. 1. Argumentless `IP` needs to apply inter-paragraph spacing even to items in compact lists. 2. `LE` needs to break the line and cancel any indentation implied by the open list even when not followed immediately by a paragraphing macro. Regards, Branden
signature.asc
Description: PGP signature
