[Bug-gnu-utils] Re: std make algorithm fails to identify obviously missing sources

[Wayne Throop]

::: "Ron Burk" <address@hidden>
::: --------------------
::: OBJS = foo.obj
::: 
::: foo : $(OBJS) link_cmd $? 
::: 
::: $(OBJS) : foo.h
::: --------------------

:: address@hidden (Bob Proulx)
:: If you add an implicit rule for your specific situation then this
:: will work properly. 

: "Ron Burk" <address@hidden>
: But I believe you're not right about that. 

Let's demonstrate a specific behavior to discuss.

    bash$ mkdir empty
    bash$ cd empty
    bash$ :>foo.h
    bash$ cat >makefile
    OBJS = foo.o
    foo: $(OBJS); link_cmd $?
    $(OBJS): foo.h
    bash$ make
    link_cmd foo.o
    make: link_cmd: Command not found
    make: *** [foo] Error 127
    bash$ rm *
    bash$ :>foo.h
    bash$ cat >makefile
    OBJS = foo.o
    foo: $(OBJS); link_cmd $?
    $(OBJS): foo.h
    $(OBJS): %.o: %.c
    bash$ make
    make: *** No rule to make target `foo.c', needed by `foo.o'.  Stop.

I presume the point is that the broad hint embodied in that line

    $(OBJS): %.o: %.c

shouldn't be necessary for make to figure out that it either ought to
consstruct or be provided with foo.o, since make has a suffix rule to
make .o files from .c files.  But I don't think make's behavior here is
unreasonable; you just gave it an EXplicit dependency, but without a
body.  Make is *supposed* to ignore implicit rules in the presense of
explicit ones. 

Now, per Paul D.  Smith's comments, I presume the fix you have in mind was
for make not to ignore implicit rules in that case or some such, and
that that's how you tell the difference between

     foo: bar
     bar: baz

where bar isn't a file and is just passing along a "collection", and

     foo: foo.o
     foo.o: foo.h

where foo.o IS f file.  That is, make should know the difference between
foo.o and bar in those cases, because there's an implicit rule for the
one and not the other.  Eh.  Maybe.  I would *not* agree it was a good
idea that make should know foo.o is a file rather than a placeholder
because it got mentioned via $? in the rule body; that seems a bad idea,
ie, spoofed by things like "echo building $@ from $?" and the such.

But on the other hand, while I don't think make's behavior is
unreasonable, I don't think it's unreasonable for make to make the above
distinction based on the presense of an implicit rule for the .o suffix
either.  The principle of least surprise would tend to favor this DWIMish 
behavior, even though the explicit rule says otherwise.

Finally, on the gripping hand, I loath depending on the implicit
suffix rules anyways, so I'm not annoyed at needing $(OBJS): %.o: %.c
or some such.  But that's just me.

Wayne Throop   address@hidden   http://sheol.org/throopw
"He's not just a Galaxy Ranger... he's a Super-Trooper!"