bug#18955: Makefile:382: recipe for target 'src' failed

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 9 Nov 2014 18:42:06 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
> To be honest, from my point of view, workarounds like `unmsys--file-name' all
> over the place are not a good idea. Look at the path passed:
> 
>     /C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt
>    
> 
> I get it that on Windows, Emacs currently gets confused and as a last resort
> tries to prepend "c:", hence:
> 
>     Opening input file: no such file or directory,
>     c:/C/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs/src/emacs/admin/unidata/IVD_Sequences.txt

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

To do this, we'd have to drag this support all the way down to the
lowest level where we pass file names to the OS APIs.  And then we'd
have to disallow root directories of one letter, like C:/c, which are
entirely legitimate.  All that just to handle the few commands during
the build process that need it.  I find this solution even more ugly
than the unmsys--file-name gork.

IOW, the MSYS build process needs a few ugly tweaks to make it work.
I consider those ugly tweaks a necessary evil, but making ugly hacks
in Emacs per se just to support these tweaks sounds excessive and
unjustified, since the ratio of the number of people who build Emacs
to the number of those who just use it is quite small.  Letting those
many suffer inconveniences and limitations so that the few could live
easier sounds wrong to me.