GNU bug report logs - #18955
Makefile:382: recipe for target 'src' failed

Previous Next

Full log

View this message in rfc822 format

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Alexander Shukaev <haroogan <at> gmail.com>, 18955 <at> debbugs.gnu.org
Subject: bug#18955: Makefile:382: recipe for target 'src' failed
Date: Sun, 9 Nov 2014 21:10:58 +0100

> It's not Emacs who becomes confused, it's MSYS.  When MSYS invokes a
> native Windows program, it converts /c/foo/bar file names into the
> Windows C:\foo\bar form, because otherwise native Windows programs
> will not be able to access such files.  There's some logic in MSYS
> that is used to decide when to do this conversion, and that logic
> fails when the /c/foo/bar file name is not at the beginning of the
> command-line argument, as in this case.

Indeed, and FWIW, that logic is documented here:

  http://www.mingw.org/wiki/Posix_path_conversion

>  That's why we use
> unmsys--file-name: to paper over these failures of MSYS.
>
>> I believe it's better to teach it to treat "/C" as "C:" by default, i.e. to
>> accept both variants because there is no ambiguity here and, as a result, it
>> will support both Windows and MSYS(2)/Cygwin paths out of the box.

MSYS paths are not only those of the form "/c/foo".  For example:
"/home/dani/foo", "/usr/local" and, in general any UNIX-like path are
valid MSYS paths.

And moreover, any MSYS path could be mounted to any Windows-native
path (type "mount" to see the current mapping).

Therefore, it is clear that supporting MSYS/Cygwin paths from the
MS-Windows port of Emacs is far more complex that simply translating
"/C" into "C:".

-- 
Dani Moncayo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.