Re: an angry rant about *BSD Make

[Ingo Schwarze]

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 pattern rule ("%.me: %.me.in") is not portable to NetBSD or
> #     OpenBSD make.

And probably to most other make(1) implementations except gmake(1).

> # 2.  A double-suffix rule won't work because the semantics of the rule
> #     are that the suffix is replaced, not removed.

I don't follow.

This works for me and seems pretty simple and straightforward:

  SUFFIXES += .me.in

  .me.in.me:
        $(GROFF_V)$(MKDIR_P) `dirname $@` && $(DOC_SED) $< >$@

Yes, the automatic generation of .SUFFIXES by automake(1) is awkward and
sometimes generates bogus .SUFFIXES entries.  It would probably be better
if automake just let the user write the .SUFFIXES rules manually instead
of guessing half of them and creating the other half from $SUFFIXES.
I mean, these lines are always short and easy to write for a human,
whereas fixing stuff up when automake(1) guesses wrong can be icky.
But these quirks of automake(1) are not the fault of make(1).

> # 3.  A single-suffix rule works in an isolated Makefile, but _only_
> #     with the .SUFFIXES special target, not with the SUFFIXES macro.
> #     (Is the latter a bug?)
> #       .SUFFIXES: .in
> #       .in:
> #             $(DOC_SED) $< >$@
> #
> # (One can raise a valid complaint that the above may be too general.)

I agree.  For most ".in" to "no suffix" transformations, you do
not want to use DOC_SED.  I think your idea to be more specific
and state for which file types DOC_SED is supposed to be used
makes a lot of sense.

> # But...
> #
> # 4.  GNU Automake insists that we use the SUFFIXES macro and not the
> #     special target.
> #       error: use variable 'SUFFIXES', not target '.SUFFIXES'
> # 5.  So we have to use target rules,

I don't this that conclusion follows from what you said before.

Yours,
  Ingo