From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18955: Makefile:382: recipe for target 'src' failed Date: Sun, 09 Nov 2014 22:28:42 +0200 Message-ID: <83r3xcnmo5.fsf@gnu.org> References: <0d4mudlgty.fsf@fencepost.gnu.org> <83ppd1t2eh.fsf@gnu.org> <83fvdwthpx.fsf@gnu.org> <8361est9ri.fsf@gnu.org> <838ujnrq7v.fsf@gnu.org> <83389vrow2.fsf@gnu.org> <83wq74nuwq.fsf@gnu.org> <83vbmonoky.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1415564964 20021 80.91.229.3 (9 Nov 2014 20:29:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Nov 2014 20:29:24 +0000 (UTC) Cc: 18955@debbugs.gnu.org To: Alexander Shukaev Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 09 21:29:17 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XnZ6q-0007rg-OO for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Nov 2014 21:29:16 +0100 Original-Received: from localhost ([::1]:39907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnZ6q-0006XT-CJ for geb-bug-gnu-emacs@m.gmane.org; Sun, 09 Nov 2014 15:29:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnZ6i-0006XL-SK for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 15:29:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnZ6c-0004wF-QW for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 15:29:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnZ6c-0004wB-Nz for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 15:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XnZ6c-0000Dy-7X for bug-gnu-emacs@gnu.org; Sun, 09 Nov 2014 15:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Nov 2014 20:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18955 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18955-submit@debbugs.gnu.org id=B18955.1415564938849 (code B ref 18955); Sun, 09 Nov 2014 20:29:02 +0000 Original-Received: (at 18955) by debbugs.gnu.org; 9 Nov 2014 20:28:58 +0000 Original-Received: from localhost ([127.0.0.1]:55142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnZ6Y-0000Dc-2d for submit@debbugs.gnu.org; Sun, 09 Nov 2014 15:28:58 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:33925) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XnZ6V-0000DS-98 for 18955@debbugs.gnu.org; Sun, 09 Nov 2014 15:28:56 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NES00N00G90OV00@mtaout24.012.net.il> for 18955@debbugs.gnu.org; Sun, 09 Nov 2014 22:21:32 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NES00G58GJW4880@mtaout24.012.net.il>; Sun, 09 Nov 2014 22:21:32 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95798 > Date: Sun, 9 Nov 2014 21:13:17 +0100 > From: Alexander Shukaev > Cc: 18955@debbugs.gnu.org, Glenn Morris > > 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.