Re: AT&T troff requests

Hi, Humm wrote on Tue, Mar 29, 2022 at 06:51:34AM +: > Quoth G. Branden Robinson: >> Someone wrote: >>> As far as I can tell, none of them are mentioned in the Troff User’s >>> Manual (CSTR 54, Plan 9, and Heirloom versions), in Mandoc docs, or in >>> Groff docs. I suggest mentioning these s

Re: building groff with GNU Make and *BSD Make

Hi Branden, G. Branden Robinson wrote on Tue, Mar 29, 2022 at 06:26:14AM +1100: > At 2022-03-28T12:11:32-0700, Larry McVoy wrote: >> Just pick one, we picked GNU make, not my favorite by any stretch but >> it runs everywhere. Build the makefiles for that make and call it a >> day. > Some people

Re: building groff with GNU Make and *BSD Make

Hi Ingo, First of all, I mean no disrespect to you personally, I've enjoyed your posts to this list. On Tue, Mar 29, 2022 at 05:31:57AM +0200, Ingo Schwarze wrote: > > On Tue, Mar 29, 2022 at 06:26:14AM +1100, G. Branden Robinson wrote: > >> At 2022-03-28T12:11:32-0700, Larry McVoy wrote: > > >>

Re: building groff without makeinfo (was: lots of fatal build system bugs)

Hi Branden, G. Branden Robinson wrote on Tue, Mar 29, 2022 at 06:15:51AM +1100: > I wanted to get your feedback on another point. > > commit aa16fc0fe503e462617b4db2da1e7638bcac77c6 > Author: G. Branden Robinson > Date: Wed Mar 2 03:22:40 2022 +1100 > > INSTALL.extra: Update discussion o

Re: building groff with GNU Make and *BSD Make

Hi Larry, i think we agree that one syntax should be picked. Nobody is proposing that two or more separate Makefiles should be maintained. The point we appear to disagree on is this: You seem to say "Pick *any* specific program, use the full feature set of one particular version of that specifi

Re: building groff with GNU Make and *BSD Make

On Tue, Mar 29, 2022 at 04:53:39PM +0200, Ingo Schwarze wrote: > You seem to say "Pick *any* specific program, use the full feature > set of one particular version of that specific program, and add a > hard dependency on that specific version of that specific program." No, I didn't say that, I sai

Re: building groff without makeinfo

Hi, Ingo! At 2022-03-29T16:16:54+0200, Ingo Schwarze wrote: > G. Branden Robinson wrote on Tue, Mar 29, 2022 at 06:15:51AM +1100: > > I wanted to get your feedback on another point. > > * Update discussion of our Texinfo manual since we no longer > > have a hard build-time dependency on

Re: building groff with GNU Make and *BSD Make

Hi Branden, G. Branden Robinson wrote on Tue, Mar 29, 2022 at 05:59:07AM +1100: > I'm going to drop a lot of the thread because I don't have anything > further to add to a lot of it. Totally fine, i'm usually doing the same. [...] > I took the time to read the OpenBSD make(1) page[1] and found

Re: Release Candidate 1.23.0.rc1

Hi Brandon, G. Branden Robinson wrote on Tue, Mar 29, 2022 at 05:05:52AM +1100: > Unless someone swoops in to relieve me of acting release manager > duties (please), there will certainly be a 1.23.0.rc2. Even if Bertrand shows up for the release, i'd like to strongly recommend fielding a 1.23.0.

an angry rant about *BSD Make

Here is a comment in a forthcoming commit to groff's doc/doc.am file. # Generating *.me from *.me.in is, surprisingly, a challenge. # 1. A pattern rule ("%.me: %.me.in") is not portable to NetBSD or # OpenBSD make. # 2. A double-suffix rule won't work because the semantics of the rule #

Re: an angry rant about *BSD Make

Hi Branden, G. Branden Robinson wrote on Wed, Mar 30, 2022 at 05:23:26AM +1100: > Here is a comment in a forthcoming commit to groff's doc/doc.am file. > > # Generating *.me from *.me.in is, surprisingly, a challenge. Not hard to do in a clean way, though, as far as i can see. > # 1. A patter

Re: an angry rant about *BSD Make

Hi Ingo, At 2022-03-29T21:04:54+0200, Ingo Schwarze wrote: > > # Generating *.me from *.me.in is, surprisingly, a challenge. > > Not hard to do in a clean way, though, as far as i can see. Hold that thought. > > # 1. A pattern rule ("%.me: %.me.in") is not portable to NetBSD or > > # OpenB

Re: an angry rant about *BSD Make

At 2022-03-29T21:04:54+0200, Ingo Schwarze wrote: > This works for me and seems pretty simple and straightforward: > > SUFFIXES += .me.in > > .me.in.me: > $(GROFF_V)$(MKDIR_P) `dirname $@` && $(DOC_SED) $< >$@ It _doesn't_ work for me in a stripped-down scenario. $ cat hello.me.in .p

Re: an angry rant about *BSD Make

Hi Branden, G. Branden Robinson wrote on Wed, Mar 30, 2022 at 06:37:17AM +1100: > At 2022-03-29T21:04:54+0200, Ingo Schwarze wrote: >> This works for me and seems pretty simple and straightforward: >> >> SUFFIXES += .me.in >> >> .me.in.me: >> $(GROFF_V)$(MKDIR_P) `dirname $@` && $(DOC_

Re: Question on hyperlinks in groff

Hi Chems, When reading the s.tmac file, specifically the description for the .[ > macro, it mentions a macro called .#, but I can't find its definition > anywhere. > Both the .[ and .# macros belong to the Mono package . This is a project of mine (i.e., not part o

Re: an angry rant about *BSD Make

Quoth Ingo Schwarze: Regarding your question how make(1) disambiguates: .SUFFIXES: .me.in .me .me.in.me: means "transform .me.in -> .me" .SUFFIXES: .me .in.me .me.in.me: means "transform .me -> .in.me" How widely implemented is that? As far as POSIX is concerned, the suffixes just are