Re: behavior on Win depends on whether \ or / is used??

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: address@hidden, "Mark Galeck (CW)" <address@hidden>
> Date: Sun, 03 Jan 2010 16:01:42 -0500
> 
> On Sat, 2010-01-02 at 10:43 +0200, Eli Zaretskii wrote:
> > > 
> > > vpath %.s foobar0 foobar1
> > > %.o: %.s
> > >           echo $<
> > > foobar0/foobar.s:
> > > 
> > > (and as always, foobar.s only in foobar1, not in foobar0).  
> > > 
> > > 
> > > Here, the current behavior of make is 
> > > 
> > > C:\tmp>make foobar.o
> > > echo foobar0/foobar.s
> > > 
> > > How can this possibly be "correct"??  GNU make manual only states
> > that for the rule with no commands or prerequisites, make "imagines"
> > the target has been updated, even if it does not exist.
> 
> I guess I'm not sure what comment I should make... you have described
> the answer yourself.  If there is a target with no prerequisites or
> recipe, make treats it as if it was created when make runs (so it's new,
> every time).

Make needs to build foobar.o, so is looking for foobar.s, right?  And,
as Mark points out, in this little experiment, foobar.s exists _only_
in foobar1, not in foobar0.  So why does make pick up foobar0/foobar.s
(which does not exist), rather than foobar1/foobar.s?  By the way, if
you switch the order of foobar0 and foobar1 in vpath, Make does TRT,
AFAIR, and picks up foobar1/foobar.s.  This inconsistency is in itself
a problem, I'd say, no?

> And, how does this relate to the subject of the email (slash vs.
> backslash)?

Check out the thread in the archives: the original Makefile, which
used mixed forward- and backslashes, exacerbated the inconsistent
behavior because when we hash file names, the two flavors of slashes
are hashed differently, so Make would think that foobar1/foobar.s
exists but foobar1\foobar.s does not, or something along those lines.
So I asked for your opinion on whether it would do any harm to modify
the file name hash function to treat a backslash as if it were a
slash.

But let's first understand the ``correct'' behavior on GNU/Linux,
before we dive into Windows idiosyncrasies...

TIA