[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows make invoking cygwin sh bug
From: |
Eli Zaretskii |
Subject: |
Re: Windows make invoking cygwin sh bug |
Date: |
Fri, 18 Mar 2011 17:07:25 +0200 |
> Date: Fri, 18 Mar 2011 09:34:55 -0400
> From: Alex Khripin <address@hidden>
> Cc: address@hidden
>
> > 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.
- Windows make invoking cygwin sh bug, Alex Khripin, 2011/03/18
- Re: Windows make invoking cygwin sh bug, Eli Zaretskii, 2011/03/18
- Re: Windows make invoking cygwin sh bug, Alex Khripin, 2011/03/18
- Re: Windows make invoking cygwin sh bug,
Eli Zaretskii <=
- Re: Windows make invoking cygwin sh bug, Alex Khripin, 2011/03/18
- Re: Windows make invoking cygwin sh bug, Eli Zaretskii, 2011/03/18
- Re: Windows make invoking cygwin sh bug, Alex Khripin, 2011/03/18
- Re: Windows make invoking cygwin sh bug, Eli Zaretskii, 2011/03/18
- Re: Windows make invoking cygwin sh bug, Rob Walker, 2011/03/18
- Re: Windows make invoking cygwin sh bug, Rob Walker, 2011/03/18
Re: Windows make invoking cygwin sh bug, David Highley, 2011/03/18