> From: Paul Smith <psm...@gnu.org>
> Date: Mon, 25 Sep 2017 11:48:11 -0400
>
> On Sun, 2017-09-24 at 15:43 -0700, Paul Eggert wrote:
> > Paul Smith wrote:
> > > I can't answer your question, but the previous version of this
> > > function didn't do anything special with a "foo/" path, so if it
> > > doesn't work here it didn't work there either...?
> >
> > Now I *know* I should have kept my mouth shut. :-)
> >
> > Sorry, I'm lost here, partly because I don't know what is meant by
> > "previous version". I guess you're working in a private repository
> > and that I can't see what version is the "latest". I trust your
> > instinct for MS-Windows code more than I trust mine, so if you think
> > the latest version is OK then that's good enough for me.
>
> Well, that's sad on both our parts :). I usually bumble along until
> Eli whacks me on the head and points out where my POSIX blinders have
> led me.
Not sure whether we are there already with this discussion. ;-)
Anyway, Paul Eggert is right, in that, if some code assumes that
"foo/" should have the semantics of 'foo' being a directory, then the
corresponding MS-Windows APIs emulating Posix functions will not
generally support that. One example I know of is this:
int foo_is_a_directory = access ("foo/", F_OK) == 0;
AFAIU, on Posix platforms the trailing slash makes sure that 'foo'
exists and is a directory, but on Windows the slash is removed before
the filesystem is queried, so the directory semantics is lost. On
Windows, one needs to use D_OK (which is not universally supported),
or check for a directory separately.
That said, I'm not sure the above is relevant for the issue at hand.
Is it? Are there other situations where Make uses "foo/" and expects
that to mean that 'foo' is a directory? If so, what are those cases,
and could someone please point me to the relevant code in Make that I
should review?
Thanks.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
