Hi Branden, > Date: 2026-08-23 20:11:29-0500 > From: "G. Branden Robinson" <[email protected]> > > Hi Alex, > > At 2026-08-24T01:11:00+0200, Alejandro Colomar wrote: > > I believe the reason I avoid learning m4 is that I don't think I need > > it. So far, GNU Make has proved to be enough for me. The day I find > > myself writing a build system for a project, and find it impossible or > > impractical to do it using GNU Make, I'll give autotools a chance. > > But I haven't found anything yet that I can't do easily with GNU Make. > > > > I have yet to be convinced that autotools provide any benefits over > > GNU Make. > > For me, the biggest benefit of GNU Automake is the test harness that's > just lying there. It's stupidly easy to add a new test script.[0] > > [0] Example: > > > https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=aa43b5e261a7b4fe3b09e6673f145b0e123faffa
The marginal cost of adding one test is small (but nonzero), but is that also true for the first test? FWIW, I used the build system of the man-pages for a C library project, and while I obviously had to add some makefile code for adding tests, the marginal cost of adding one test file is zero. That is, the makefiles find anything under share/tests/, and include it to the file list. [...] > [I wrote:] > > > 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). > > > > Indeed, I use only GNU Make. > > > > <https://make.mad-scientist.net/papers/rules-of-makefiles/> > > > > Paul's first of the Rules of Makefiles: > > > > 1. Use GNU make. > > > > Don’t hassle with writing portable makefiles, use a portable > > make instead! > > > > Once POSIX Issue 8 make(1) gets more wide spread, I might put some > > effort into transforming some GNU idioms into POSIX idioms, if it's > > easy. > > Should be. The only change I can think of off the top of my head is > that you'll need to covert > > FOO:=bar > > to > > FOO::=bar > > ...because BSD implemented `:=` with different semantics. Less useful > ones, but they planted their feet. > > `:=` is therefore ambiguous. (If one wants BSD `:=` semantics, one uses > the truly ghastly `:::=`. Serves 'em right! 3;-) ) Thanks! I've applied the following commit. commit af165bbd04c6f85c66a33452b1d247f32c926ae6 Author: Alejandro Colomar <[email protected]> Date: 2026-08-24 12:12:11 +0200 share/mk/, GNUmakefile: Use ::= instead of := That's what POSIX.1-2024 standardized. Suggested-by: "G. Branden Robinson" <[email protected]> Message-ID: <20260824011129.njsipdzmay4smp6i@illithid> Signed-off-by: Alejandro Colomar <[email protected]> diff --git a/GNUmakefile b/GNUmakefile index 3f2ea50baa66..f8b3add5b325 100644 --- a/GNUmakefile +++ b/GNUmakefile @@ -2,8 +2,8 @@ # SPDX-License-Identifier: LGPL-3.0-only WITH LGPL-3.0-linking-exception -SHELL := bash -.SHELLFLAGS := -Eeuo pipefail -c +SHELL ::= bash +.SHELLFLAGS ::= -Eeuo pipefail -c ifneq (4.4.999,$(firstword $(sort 4.4.999 $(MAKE_VERSION)))) [...] > > > $ wc -c $(find -name "*.am" | grep -v gnulib | sort) > > > > Out of curiosity, why would you use $()? It feels simpler (less > > nesting) to use xargs(1). It's also more robust, since the output of > > $() might grow in some cases too much for a single command. > > I seldom (if ever) encounter the final difficulty. When working > interactively at the command line, I'm practically never trying to hunt > up things across an entire file system. Just $HOME is too big to be > wieldy. If I really have to trawl my gigantic $HOME, I write a script > and go do something else for a while. > > > $ find -name "*.am" | grep -v gnulib | sort | xargs wc -c | tail -n1 > > 228376 total > > You can see that my "phrasing" is shorter. Nice for interactive use. $() vs |xargs is only shorter by a 3 characters. Also, $() has three characters for which you have to hold shift, vs 1 from |xargs, which makes $() actually harder to type than |xargs, IMHO. Some interesting feature of |xargs is that you can prepend it with '|tee /dev/tty' when you need to debug the input, when something goes wrong. [...] > > grep(1) seems simpler to learn, > > since we already know it anyway. > > Necessary link: <https://doc.cat-v.org/unix/find-history>. > > Oh, hah. Yes. I'll ask you to take my word for it that I wrote my > historical summary above before reading this part of your message. ;-) :-) [...] > > Interesting. The day someone complains again about my makefiles, I'll > > point to this data. I checked a few other projects out of curiosity: > > > > alx@devuan:~/src/shadow/shadow/master$ find | grep '\.am$' | grep -v > > gnulib | sort | xargs wc -c | tail -n1 > > 31885 total > > alx@devuan:~/src/gnu/glibc/master$ find | grep '\.am$' | grep -v gnulib > > | sort | xargs wc -c | tail -n1 > > 0 > > alx@devuan:~/src/gnu/gcc/master$ find | grep '\.am$' | grep -v gnulib | > > sort | xargs wc -c | tail -n1 > > 1527474 total > > alx@devuan:~/src/gnu/coreutils/master$ find | grep '\.am$' | grep -v > > gnulib | sort | xargs wc -c | tail -n1 > > 8171 ./Makefile.am > > alx@devuan:~/src/gnu/findutils/master$ find | grep '\.am$' | grep -v > > gnulib | sort | xargs wc -c | tail -n1 > > 35765 total > > > > Does glibc not use automake? What do they use? > > Hand-written Makefiles, apparently! For a while I followed their Git > commits, but I'm well behind on them. glibc and GCC saturated my > ability to keep up with the projects I track. Oh, nice! > > > 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. > > > > It's interesting that a build system of the same size as mine but > > based on autotools remains problematic, while mine based on GNU > > makefiles consistently has zero issues. And when one is reported (a > > few in the last years), they are trivial and addressed in minutes. > > Also, *all* projects I've seen using non-make build systems > > consistently have issues they just leave there because the problem > > isn't understood. The more I see about other build systems, the more > > I like mine. > > groff may be trying to solve somewhat different problems. > > We have weird-ass problems like this: > > https://savannah.gnu.org/bugs/?68567 > > ...and I daresay you don't. I _think_ had some issues that are somewhat similar in the build system of a C library. I had to deal with them in the pkg-config file. I say I think, because I don't understand that problem enough. > 'Course, that was an Autoconf problem, not an Automake problem. But it > was still a build dependency issue, and thus ultimately had impact on > Makefiles. > > > I have to admit that writing a quality build system with GNU Make > > isn't easy. It took me many years to research, experiment, and learn. > > So, the makefile code I wrote is hardly maintainable by a novice (I > > wonder what'll happen to it after me). But the same is true of any > > good build system. > > Yeah. Not long after I took a job in Sydney, I was gifted with a > printed-out meme as decoration for my cubicle wall. Attached. :D > CMake and Australian culture taught me how to swear as if I were myself > a member of Insane Clown Posse. :-| > > > I think distro maintainers are scared of makefiles because the average > > makefile is problematic. But the same things are said of C, and I > > don't think C is particularly problematic as a language. > > Disagree with you here. C and C++ are _terrible_ languages. :D It has many dialects, and I acknowledge some of them --notably including ISO C89-- are terrible. But some dialects, such as GNU C2y, are quite nice. Please don't judge the language by its worst dialects. :) > (By multiple important metrics, English is a terrible natural language. > Its phonemic inventory is unusually large and its spelling thoroughly > unpredictable. It is about as hard for non-native speakers to acquire > as Arabic, Russian, or Mandarin or Cantonese Chinese are to monoglot > English speakers. I happen to love the English language. But I > acknowledge that it is a cruel mistress.) Phonetically, Spanish might be some of the simplest languages. On the other hand, written English is quite simple compared to other languages (including Spanish). It doesn't conjugate much. I've heard Norwegian is even simpler than English when written, and possibly one of the simplest languages. I haven't learnt it, so I can't judge. > If I ever get over the fence to the greener grass of Ada, I'll let you > know how I find it. ;-) > > > It's just the average programms that are problematic, in any language. > > Average programmers do average work in any language. The parameter over > which language designers have control is whether the work gets "done" at > all. What "done" _means_ is back in the hands of the programmer again. > [...] > > > I like your idiom of sticking `P` after the `LS` and/or the `LE` > > > calls > > > > You problably mean before the LS and after the LE? > > Actually either way works, right now. I don't plan to change that. > > $ cat ATTIC/inline-compact-list.man > .TH foo 1 2026-08-23 "groff test suite" > .SH Name > foo \- frobnicate a bar > .SH Description > This is my man page. > There are many like it, > but this one is mine. > .SS "Example 1" > People should read more about > .P > .LS itemized 1 4n > .IP \[bu] > bash > .IP > This line should be preceded by vertical space. > .IP \[bu] > m4 > .IP \[bu] > make > .LE > .P > and learn what these tools can do for them. > .SS "Example 2" > (This example should look the same as the first.) > People should read more about > .LS itemized 1 4n > .P > .IP \[bu] > bash > .IP > This line should be preceded by vertical space. > .IP \[bu] > m4 > .IP \[bu] > make > .LE > .P > and learn what these tools can do for them. > $ ./build/test-groff -rLL=72n -man -T utf8 ATTIC/inline-compact-list.man > foo(1) General Commands Manual foo(1) > > Name > foo - frobnicate a bar > > Description > This is my man page. There are many like it, but this one is mine. > > Example 1 > People should read more about > > • bash > This line should be preceded by vertical space. > • m4 > • make > > and learn what these tools can do for them. > > Example 2 > (This example should look the same as the first.) People should > read more about > > • bash > This line should be preceded by vertical space. > • m4 > • make > > and learn what these tools can do for them. > > groff test suite 2026‐08‐23 foo(1) > > > > 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. > > > > Here I've written some test page. I can't handle some cases: > > > > alx@devuan:~/tmp$ cat ls.man > > .TH a s d f > > .SH test > > compact but separated: > > .P > > .LS itemized 1 > > .IP \[bu] 3 > > foo > > .IP \[bu] > > foo > > .LE > > .P > > compact, and no space before: > > .LS itemized 1 > > .IP \[bu] 3 > > bar > > .IP \[bu] > > bar > > .LE > > .P > > compact, and no space after: // How to do this?? > > .P > > .LS itemized 1 > > .IP \[bu] 3 > > baz > > .IP \[bu] > > baz > > .P > > .LE > > compact, and no spaces before nor after: // Same problem. > > .LS itemized 1 > > .IP \[bu] 3 > > qwe > > .IP \[bu] > > qwe > > .P > > .LE > > expanded: > > .LS itemized > > .IP \[bu] 3 > > qwe > > .IP \[bu] > > qwe > > .LE > > .P > > end of file > > alx@devuan:~/tmp$ /opt/local/gnu/groff/20260823_master/bin/groff -man > > -Tutf8 ls.man > > a(s) > > a(s) > > > > test > > compact but separated: > > > > • foo > > • foo > > > > compact, and no space before: > > • bar > > • bar > > > > compact, and no space after: // How to do this?? > > > > • baz > > • baz > > > > compact, and no spaces before nor after: // Same problem. > > • qwe > > • qwe > > > > expanded: > > > > • qwe > > > > • qwe > > > > end of file > > > > f d > > a(s) > > Yup, that looks like the problem I flagged as #2 earlier. > > > > 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. > > > So, I expect you'll change 'P' to not add that blank line if it's > > within LS/LE? Or how should we write these? > > No, I _want_ `P` to add a blank line, before and internally to a list, > even a compact one. But I want `LE` to be able to configurably > _suppress_ a blank line after a compact list. Right now the simplest > thing to do seems like giving it a Boolean argument to eat. > > Right now I'm conceptualizing that argument as "post-compactness", > because that way it's likely to be consistent with any specified > "compactness" Boolean argument to `LS`, but I wouldn't count on the > former term surviving to code or documentation. I think we don't need an argument. Just a behavior fix. alx@devuan:~/tmp$ cat ls.man .TH a s d f .SH test compact, and no spaces before nor after: // Same problem. .LS itemized 1 .IP \[bu] 3 qwe .IP \[bu] qwe .LE end of file alx@devuan:~/tmp$ /opt/local/gnu/groff/20260823_master/bin/groff -man -Tutf8 ls.man a(s) a(s) test compact, and no spaces before nor after: // Same problem. • qwe • qwe end of file f d a(s) I think LE should insert at least a break. With that, we'd have this solved, I think. Have a lovely day! Alex > > Regards, > Branden > > [1] Of which this one is probably the most savage: > > > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/groff/tests/check-delimiter-validity.sh?h=1.24.1 > > [2] With one honorable exception, a *BSD luminary who contacted me > privately. Haven't heard back from him in over a year now, but > these things can take time. -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
