On Fri, Mar 18, 2011 at 4:16 AM, Eli Zaretskii <[email protected]> wrote:
> > Date: Thu, 17 Mar 2011 21:26:12 -0400
> > From: Alex Khripin <[email protected]>
> >
> > 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
_______________________________________________
Make-w32 mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/make-w32
