groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: an angry rant about *BSD Make


From: G. Branden Robinson
Subject: Re: an angry rant about *BSD Make
Date: Wed, 30 Mar 2022 06:23:33 +1100
User-agent: NeoMutt/20180716

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
> > #     OpenBSD make.
> 
> And probably to most other make(1) implementations except gmake(1).

Maybe not, but my brain parses it easily.

> > # 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.

My defense is that I tried it with a single rule in an isolated
scenario, which was the only way I could figure out enough to write my
rant at all.  I did not, however, come up with the incantation you did.

> This works for me and seems pretty simple and straightforward:
> 
>   SUFFIXES += .me.in
> 
>   .me.in.me:
>       $(GROFF_V)$(MKDIR_P) `dirname $@` && $(DOC_SED) $< >$@

I will give this a try when I finish beating on the current problem
(involing locating the dependencies in both in-tree and out-of-tree
build scenarios).

Simple, yes.

Straightforward?

I am Jack's slackjawed incredulity.

>   .me.in.me:

From which direction is the match greedy?  How is it supposed to be
obvious that this produces '.me' from '.in.me' and not 'in.me' from
'.me', the exact opposite relationship?  Who decided that target names
are only ever shorter than their prerequisites?

If the semantics are portable and stable, fine, I'll go with it--but
I'll comment it with an apology (in the formal sense of a defense of
questionable practice), because this design is a code smell from hell.
It is not remotely transparent to the reader, or any writer with less
than a full mastery of make(1).

> 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,

https://media.giphy.com/media/12Nv3nBSCAbLO0/giphy.gif

> 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).

Agreed there.  Thomas Dickey has some entertaining writings on Automake.

> > # 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.

The rant might get modified before I push, but I don't expect it to
disappear.

Thanks for the switft rescue.

>   .me.in.me:

<slow blink>

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]