RE: why is ./foobar target noted as foobar ??

[Paul Smith]

On Sun, 2012-03-04 at 00:34 -0800, Mark Galeck (CW) wrote:
> > That is, I'm OK with make recognizing that the strings "./foo" and "foo"
> refer to the same file on the disk for the purposes of determining
> out-of-dateness etc. but I don't think make should be changing the value
> of address@hidden
> 
> AMEN.  So, would it get fixed :)  Like I said, I got a Linux kernel
> break precisely due to that.

Well honestly (as you can see from the age of the original bug report)
it's not a high priority for me.  The behavior is more-or-less
documented and intentional so although I agree it's not what I would
choose, it's not technically a bug.  The behavior has been there since
before I started maintaining make and I've not heard any massive
complaints about the Linux kernel, or other major software systems,
having significant problems with it, and no doubt many many makefiles
rely on this behavior (most without even realizing it I'd guess).

And fixing it is not that simple, I suspect.  Although, we do have a
concept of a "real name" and a "hash name", to support vpath behavior.
Maybe something could be done with that.

> >Please don't top-post.
> 
> ? I am not sure what you mean.  I don't "top-post". Top-posting is
> where you put your reply and then quote the original messages in its
> entirety below.

You posted, then posted a followup to yourself which was a top-post
(your original first message was included below your followup).  This
meant I needed to reorder the message so that I could put the sample
makefile first and the problem definition next, for readability.

> > On the other hand, what should make do if it sees two rules like:
> 
> ./foo: ; @echo with dir
> foo: ; @echo without dir
> 
> Can you elaborate?

If make equates these two, then this is illegal because you're defining
two different recipes for the same target.  This is what make does today
(you get a message and one recipe is ignored).  If make doesn't know
that they're the same target, then it will accept both but which one
will be used by make when it wants to build that target?  You'd get
different behavior depending on whether your prerequisite was "foo" or
"./foo".

And if you're going to do this equivalency, it should have been
implemented completely so that regardless of the pathname all variations
were equivalent; for example:

        foo:
        ./foo:
        $(CURDIR)/foo:
        $(CURDIR)/./foo:

etc.  Today make doesn't recognize the last two as equivalent to each
other or to the first.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist