Re: Windows make invoking cygwin sh bug

> Date: Fri, 18 Mar 2011 09:34:55 -0400
> From: Alex Khripin <[email protected]>
> Cc: [email protected]
> 
> > 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 there are such problems, please report the details.  In general,
d:/foo style file names should be fully supported by the Cygwin build
of Make.

> That having been said, given that Windows make purports to be able to run
> stuff through Cygwin sh, this problem bears fixing.

But it's not a Make problem, as you correctly point out.

> > 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.

Well, then there's a bug in Cygwin as well.

> 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.

And it's a bug waiting to happen.

> 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.

That means each change in that Cygwin code will need to be
countermanded by a corresponding change in Make.  This is impractical,
because these two projects are developed by different people and at a
very different rate.

> 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!

I agree, and I think it's a bug in Cygwin.  Or maybe they think it's a
feature, since Cygwin programs are not supposed to be invoked with DOS
file names.