> Date: Fri, 18 Mar 2011 09:34:55 -0400 > From: Alex Khripin <akhri...@alum.mit.edu> > Cc: make-w32@gnu.org > > > 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. _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32