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

[Eli Zaretskii]

> Date: Sun, 9 Nov 2014 21:13:17 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 18955@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>
> 
>     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.
> 
> I'm afraid I don't understand your point here. To reiterate, the current
> problem is that Emacs does not know how to treat "/C" in the beginning,
> therefore it assumes that the path given does not have a drive letter, so it
> add "c:" in front of the given path as a wild guess.

It's not a wild guess.  File names of the form "/foo/bar" are
legitimate on Windows, so Emacs just adds the current drive to them.

If we treat /c/foo as an alias of C:/foo, users will be unable to
use, say, d:/c/foo directories.  I think this is a limitation that is
better avoided.

> The only thing that I propose to change in that logic is to allow
> paths which contain a slash + a single letter in the beginning,
> e.g. "/C", so that when Emacs sees it, it simply converts that to
> "C:" and passes further to old logic of path manipulation.

There's no single place where the "Emacs sees it" part can happen.
Emacs communicates file names to the OS through quite a few separate
APIs, so all of these places will have to know about this magic.

> In other words, nothing has to be changed to the lowest level as
> you say. My change involves one `if' statement or so in the very beginning of
> the path processing.

There's no single place where "path processing" happens, although
expand-file-name comes close.  So it's not as simple as it sounds.  It
will be quite ugly and viral.

Moreover, when file names are passed to subprocesses, we will need to
convert them as well -- like MSYS does.

> Furthermore, I don't get it why you would have to disallow "C:/c"?
> If somebody passes "C:/c" then it's perfectly valid Windows path. If
> somebody passes "/C/c", then according my proposal it will be
> converted to "C:/c" and then processed further.

That disallows saying something like

  C-x C-f /C/c/foo RET

meaning "/C/c/foo" on the current drive, like we support now.  I don't
think this limitation is justified just to solve several build
problems for which a satisfactory solution already exists.