bugmake - Bugs: bug #40657, Suffix rules and prerequisites

 
 

bug #40657: Suffix rules and prerequisites

Submitter:  John Marshall <jmarshall>
Submitted:  Thu 21 Nov 2013 02:08:34 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.81 Operating System:  Any
Fixed Release:  4.3 Triage Status:  Medium Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 20 Jan 2020 05:05:27 AM UTC, comment #5: 

This was revisited in http://git.savannah.gnu.org/cgit/make.git/commit/?id=3b5e47b2e2904884a9d853848be3348b7cdd4f8a largely thanks to a report from Dennis Clarke about building FreeBSD packages at the end of https://www.mail-archive.com/bug-make@gnu.org/msg11961.html

Martin Dorey <mdorey>
Mon 07 Oct 2019 02:01:32 AM UTC, comment #4: 


> POSIX standard is very clear


Works for me, thanks.

Martin Dorey <mdorey>
Mon 07 Oct 2019 12:05:32 AM UTC, comment #3: 

I guess I'm not quite sure what you're asking for here: what kind of diagnostic do you mean?

In general I don't like to emit diagnostics for things which are actually legal and defined makefile syntax, even if they're unlikely to be what the author actually wanted.

The problem is that the POSIX standard is very clear that a suffix (inference rule) cannot have any prerequisites so GNU make's behavior (now) is correct according to the standard.

Paul D. Smith <psmith>
Group administrator
Sun 06 Oct 2019 11:21:03 PM UTC, comment #2: 

This is now in the NEWS file as:

  • WARNING: Backward-incompatibility!

  Contrary to the documentation, suffix rules with prerequisites were being
  treated BOTH as simple targets AND as pattern rules.  Behavior now matches
  the documentation, and pattern rules are no longer created in this case.

The documentation being https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html which says:

Suffix rules cannot have any prerequisites of their own. If they have any, they are treated as normal files with funny names, not as suffix rules.

To my surprise, I find myself maintaining a Makefile which now knows only how to build a file implausibly called .c.o (to use the documentation's example).  I was in the unusually lucky position of having read the NEWS file recently.  I fear we're in for some griping here from those who spend more than the five minutes of head scratching it took me.

I wonder about a diagnostic.  Famous last words but, by the look of the code-change that accompanied the NEWS one, it doesn't look like it would be too hard.  If this never bites anyone but me, then it won't have been worth even that effort.  The chances that anyone has created a rule that looks like a suffix rule but intentionally isn't one are, at the moment, very close to zero, because they'd have to be using an unreleased version of Make.  If we leave it now, though, but come to add a diagnostic when the moans get too loud, then someone might have used it.  Then we might feel bound to add a flag to silence the warning, which is surely more trouble than this is worth.

The OP here shows that the prerequisites were being attached to the file with the funny name, which is clearly not what the author intended, at least in the example I'm faced with.  Attaching the prerequisites to the generated pattern rule, wouldn't that be the best of all worlds?  He said, idly, not volunteering a patch.

Martin Dorey <mdorey>
Sat 08 Sep 2018 09:44:01 PM UTC, comment #1: 

I think this is actually a bug, not a documentation error.  Or I guess, it could also be a documentation error, depending on how the bug is resolved.

It should not be the case that a suffix rule with a prerequisite creates both a pattern rule (without an extra prerequisite) AND an explicit rule named for the suffix (with a prerequisite).  That is bogus.

It should create either one or the other.

My inclination is to follow the documentation and keep the explicit rule and not create a pattern rule any longer.

Paul D. Smith <psmith>
Group administrator
Thu 21 Nov 2013 02:08:34 PM UTC, original submission:  

The "Suffix Rules" info node states

"Suffix rules cannot have any prerequisites of their own.  If they have any, they are treated as normal files with funny names, not as suffix rules."

However this appears to be incorrect.  Here is the example following that text, with -DHELLO added so we can see it for certain:

$ cat badsuffix.mk
.c.o: foo.h
$(CC) -DHELLO -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
$ touch hello.c

$ make -f badsuffix.mk -n hello.o .c.o
cc -DHELLO -c   -o hello.o hello.c
make: * No rule to make target `foo.h', needed by `.c.o'. Stop.

$ make -f badsuffix.mk -p | grep -B4 -A1 'badsuffix.mk.*line 2'
[snip]
%.o: %.c
# commands to execute (from `badsuffix.mk', line 2):
$(CC) -DHELLO -c $(CFLAGS) $(CPPFLAGS) -o $@ $<
--
.c.o: foo.h
# Implicit rule search has not been done.
# Modification time never checked.
# File has not been updated.
# commands to execute (from `badsuffix.mk', line 2):
$(CC) -DHELLO -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

So both a suffix rule and a rule for a funnily-named file have been made, and only one got the prerequisite.  Perusal of the NEWS file suggests that this may have changed in 3.58 ("Suffix rules may have dependencies (which are ignored)"), but it seems that the documentation has not caught up.

John Marshall <jmarshall>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mdorey (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by jmarshall (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-15 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.3
    2018-09-08 psmith Item GroupDocumentation Bug
        Triage StatusNone Medium Effort

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code