> From: Paul Smith <psm...@gnu.org> > Cc: bug-make@gnu.org > Date: Tue, 20 Dec 2016 00:31:50 -0500 > > On Sun, 2016-12-18 at 22:10 +0200, Eli Zaretskii wrote: > > > Maybe it would be clearer what the issue was if we removed the second > > > colon: > > > > > > foo:/bar ; @echo hi > > > > > > In UNIX this would be "foo : /bar ; @echo hi" which is a valid rule. > > > > On Windows, this is ambiguous, i.e. it invokes "undefined behavior". > > There's no reason for Make on Windows to second-guess that the user > > meant "foo : /bar". (In practice, no one writes such rules, certainly > > not on Windows.) > > Well, that's a perfectly valid makefile and the POSIX standard specifies > exactly how it should be parsed. I can't see any reason why Windows > should not following the standard in this case. It's simple for make to > realize that "foo:/bar" is not a valid path on Windows and hence, it > must be parsed as "foo : /bar". > > Now, if the rule was this: > > c:/bar ; @echo hi > > that would be a lot harder to recognize; in theory we could do so, since > there's only one legal way to parse this.
What about this: cc:/bar ; @echo hi Is it better to emit an error or silently parse as cc : /bar ? > > Well, one issue is that a target name doesn't have to be a valid file > > name, right? Do we want to support such target names? > > It doesn't have to be a valid filename, no. But we still have to parse > the line. In the absence of any particular reason (e.g., supporting > drive letters when HAVE_DOS_PATHS is set) I'd prefer to have the parsing > of the line behave the same on Windows and UNIX. But it already doesn't behave the same. And if the target name doesn't have to be a valid file name, then we cannot make decisions based on its validity as a file name. > > And I still feel we should have some kind of formal definition of what > > constitutes a valid line parsed by that function. Leaving this to the > > code to tell is less desirable, IMO. > > I can improve the comments for that function; unfortunately while it > does explain a lot it doesn't mention the stopmap argument. That'd be helpful, thanks. > The behavior I propose to implement is that in the case where > HAVE_DOS_PATHS is set, and where we can determine that we stopped at > the second character in the current filename which is equal to ":", and > the first character was [A-Za-z], and the third character is "\" or "/" > (by your request), then we'll assume that this colon is actually part of > the filename and we won't stop parsing the string, but instead we'll > continue until the next valid stopping point; if that's another ":" in > the string before the end of the current filename then we won't treat > that one specially and will recognize it as a stop character. I'm unconvinced wrt which alternative is better, and I don't think anyone complained about that code since it was written. But you are the Make maintainer, and you certainly know the codebase better than I do. So I will yield to your opinions. Thanks. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make