Re: Windows make invoking cygwin sh bug

[Alex Khripin]

On Fri, Mar 18, 2011 at 4:16 AM, Eli Zaretskii <address@hidden> wrote:

> Date: Thu, 17 Mar 2011 21:26:12 -0400
> From: Alex Khripin <address@hidden>

>
> Short summary: there's a bug (I blame Cygwin, but want to fix make) in
> running commands that start with a drive letter when using Windows make and
> Cygwin sh

Why are you using a native build of Make with Cygwin tools?  Doing
that is asking for trouble due to subtle incompatibilities like this
one.  The Cygwin build of Make is a much better candidate for this
kind of job, and it does support DOS/Windows file names with drive
letters.  Can you use that instead?  If not, why not?

I had some initial problems getting it to run and thought it was due to : pathnames in our .d files. If that's not the cause, I'll investigate it further - I agree that this would be the best solution. I'll try to get it working this weekend - it could be something as simple as our makedepend (which I haven't looked into carefully) making DOS-style newlines.
To clarify, we mostly use win32 tools (like MSVC and Windows QT) in our build system.
That having been said, given that Windows make purports to be able to run stuff through Cygwin sh, this problem bears fixing.

> When building the command line for cygwin (to be passed tinto
> CreateProcess), look for arguments that start with a drive letter, and
> escape them using a different method.

This is a no-starter.  Make has no knowledge about the semantics of
the arguments of the commands it invokes, so it can never be sure that
"d:/" is a drive letter of a file name.  It could be something
entirely different, like a Sed editing command, or part of a Grep
pattern, or even a quoted file name that should be passed verbatim to
the program to be used by it.  Adding something like that to Make will
introduce subtle bugs that would keep this list busy for the next 10
years.

I think you have misunderstood my bug report.
The cygwin command line parser _also_ does not understand that d:/ is a file name.
It doesn't care - it will mangle it all the same. In the cygwin source, under winsup/cygwin/dcrt0.c look at the globify function:
  int dos_spec = isdrive (word);
  if (!dos_spec && isquote (*word) && word[1] && word[2])
    dos_spec = isdrive (word + 1);
"isdrive" is
#define isdrive(s) (isalpha (*(s)) && (s)[1] == ':')

This is applied to every argument passed in on the command line from a non-Cygwin binary.

Thus, Make doesn't have to be able to decide if it's a path. All make has to do is mirror the logic of the cygwin program loader so that sh.exe gets arguments that are not mangled. I think if you look at my example, you'll agree that the current state of affairs is unacceptable - imagine it doing that to your sed-like editing command!

Thanks for the response,
Alex