I tried .SUFFIXES: but now make tried to build the program even though lex.yy.o is a prerequisite, and is missing, without any complaints. This is, of course, because I have a rule which gives a dependency from lex.yy.o to lex.yy.c, but which has no recipe.

I then added .o.c to suffixes, in hopes that  this would turn on rules involving .o and .c files only.

The lex.yy.o: lex.yy.c rule now started to work again.

But alas, the bad rule now kicked in!

$ make
lex -i -8 hc.l
cc -g -Wall -W -ansi -D_XOPEN_SOURCE=500    -c -o lex.yy.o lex.yy.c
lex.yy.c:4548:17: warning: ‘yyunput’ defined but not used [-Wunused-function]
lex.yy.c:4589:16: warning: ‘input’ defined but not used [-Wunused-function]
lex  -t hc.l > hc.c   <--- HUH?

Is that a bug? This is make 3.81 on Ubuntu 11.04.

If not, what is the real way to put the through the heart of this beast (and anything like it, known or unknown), without losing the useful implicit rules?

How can I say, "I want only the implicit rules which involve only these file types and do not involve any other file types."

What if these dangerous implicit rules made a rotating backup of their victim? What is the downside?

    mv foo.c.keep.1 foo.c.keep.2
    mv foo.c foo.c.keep.1
    mv y.tab.c foo.c

Also, another consideration is that the prerequisite .y is involved in an explicit rule.   If an implicit rule matches some file as a prerequisite, but that file is already used as a prerequisite in some rule, then those rules are competing. Maybe make should assume that the explicit rule takes precedence.

I'm not so confident about this because there are situations where something is a prerequisite to more than one rule. (Like the obvious case of a header file being a dependency for many objects).

Nevertheless, there are situations where prerequisites are typically understood to be processed by just one rule. You probably would not want to pass a .y file through yacc twice in two different rules. If such a situation exists, and one of the rules is generated from an implicit template, but the other one is explicit, somehow the explicit one should win.

Or some syntax could denote ``weak'' rules.

You know how there are order-only prerequisites; there could be a similar extension to denote weak-exclusive prerequisites, and another extension to denote clobbers.

For the sake of concrete discussion, let's use the characters @ and & for clobbers and exclusive prerequisites. The rule could then look like:

  %.c: & %.y @ y.tab.c
     $(YACC) ...
     mv ...


So now, if the rule matches some ``foo'' stem, we have a target foo.c, a exclusive prerequisite foo.y, and a clobber y.tab.c.

The exclusive prerequisite tells make that this rule must be exclusive for that prerequisite. If two explicit rules are exlusive for the same prerequisite, then the situation is erroneous: a diagnostic is emitted and the make fails. If the exclusivity conflict is between an implicit and explicit rule (like the above case), then the implicit rule is treated as weak: it is resolved in favor of the explicit rule.

The clobber element y.tab.c informs make that the rule body destroys the file y.tab.c, which is neither a target nor prerequisite.  Make will suppress this rule if y.tab.c appears as a target or prerequisite in any other rule (possibly with some warning diagnostic?). Moreover, if two or more rules both specify y.tab.c as a clobber, the execution of those rules will be serialized (in either order, just not parallel).

Note that this allows phony clobber files to be used as mutexes for serializing rules, which could be handy! Suppose that two rules exist which, say, do something destructive in the same CVS sandbox (like an update) which can modify the CVS/Entries and whatnot. They could have a clobber called ``cvs-mutex'', and make would thus not run those rules in parallel. This may be easier than inserting fake dependencies to enforce an order. I know there is .NOTPARALLEL, but that's a big hammer.

First let me point out that the behavior you're concerned about is actually required by the POSIX standard for make; the standard requires this as a built in rule to all conforming implementations:

.y.c:
    $(YACC) $(YFLAGS) $<
    mv y.tab.c $@

So we can continue to discuss this to see if there's some way to alleviate the potential bad effects, but ultimately I'm not going to remove this rule or modify it in a way that breaks the standard (and also many makefiles out there which are written to expect this behavior).

The heuristics you suggest for detecting yacc-generated files are not acceptable.  Any builtin rule MUST be completely portable to all platforms that make runs on, which includes not only all POSIX platforms with just /bin/sh, not bash, as shells, but also VMS, Windows, DOS, OS/2, and Amiga platforms (currently) where other tools like "diff" might not even exist.  Furthermore, different implementations of yacc may well generate different output in the first 3 lines.  This is simply not robust OR portable enough to be included as the builtin rule for GNU make.

The complaint about make updating foo.c from foo.y even though foo.c already exists is a primary feature of GNU make (see the manual discussion of implicit rule chaining).  Even if I wanted to, which I don't, there's no way to change this without breaking the vast majority of GNU makefiles, which rely on this very useful behavior in some form.

A builtin rule that builds a .o directly from a .y doesn't help your situation unless the current rule to build a .c from a .y were also removed completely, and that's not going to happen.

You can, of course, disable these rules in your own makefiles in various ways.

Re: what can be done about it.

Enough silly venting. How about the question of what can be done about it? I have an idea. How about a check to see whether the .c file to be clobbered is actually a yacc-generated file?

If the file already exists, only do the move if, say, the first three lines of the the file are different from the first three lines of y.tab.c.

Otherwise emit a diagnostic.

If you have GNU bash, or some other shell which supports process substitution, the logic can be expressed as:

  # Do the rename if $target does not exist, or if it
  # matches source in the first three lines.
 
  if ![ -e "$target" ] || !diff <(head -3 "$source") <(head -3 "$target"); then
    mv -- "$source" "$target"
  else
    echo "refusing update $target by replacing it with $source"
    echo "target seems to have contents unrelated to $source"
  fi

Of course, it has to be done according to whatever portability guidelines apply to the ruleset.

The downside would be that the rule refuses to do the move when it should: there is a false difference in the first three lines on every incremental rebuild. This might happen if the yacc implementation does something different in the first three lines (like adding a date stamp). Or (probably very unlikely) if edits in the actual yacc spec are reflected in an actual change in the first three lines.

The output of Bison does have a date stamp in the first three lines, but it's not generated; it's part of the boiler plate. For example:

#ifndef lint
static char const
yyrcsid[] = "$FreeBSD: src/usr.bin/yacc/skeleton.c,v 1.28 2000/01/17 02:04:06 bde Exp $";

This stamp won't change unless someone checks in the generated parser under version control which not only does RCS keyword expansion, but recognizes and expands the custom FreeBSD keyword.

Suppose your CVS does that. So you'd be doing a ``cvs up'', and then a ``make'', and ... oops! The parser.c got refreshed, so did parser.y, and now GNU make refuses to rename y.tab.c to parser.c, because CVS modified the $FreeBSD: ... $ text.

You would have to "rm parser.c" and run make again.

This is how the default rule for building YACC files in GNU make has always been, for 20-odd years.  From the GNU make manual section "Catalog of Rules":

Yacc for C programs
    n.c is made automatically from n.y by running Yacc with the command `$(YACC) $(YFLAGS)'.
Lex for C programs
    n.c is made automatically from n.l by running Lex. The actual command is `$(LEX) $(LFLAGS)'.

Creating a statically-named "y.tab.c" from "foo.y" was an inane idea in the first place: what happens if you have two different YACC files that generate different parsers in the same directory?  Ditto, of course, for lex.

I'm not sure what we can do about this.