From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.bugs Subject: bug#14513: 24.3.50; Site load-path pieces differ in MSYS build Date: Sat, 1 Jun 2013 19:00:03 +0100 Message-ID: References: <83y5aw4e0x.fsf@gnu.org> <83r4go49dg.fsf@gnu.org> <83hahk467a.fsf@gnu.org> <83ehco42t6.fsf@gnu.org> <837gif4qni.fsf@gnu.org> <83r4gn2xhk.fsf@gnu.org> <838v2t23c5.fsf@gnu.org> <8361xx20lb.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01635502400dd304de1b80b9 X-Trace: ger.gmane.org 1370109629 31729 80.91.229.3 (1 Jun 2013 18:00:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 1 Jun 2013 18:00:29 +0000 (UTC) To: Eli Zaretskii , Stefan Monnier , 14513@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 01 20:00:28 2013 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 1Uiq6N-0003vY-Ph for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Jun 2013 20:00:28 +0200 Original-Received: from localhost ([::1]:52179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uiq6N-0003hX-Gz for geb-bug-gnu-emacs@m.gmane.org; Sat, 01 Jun 2013 14:00:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uiq6I-0003hH-AY for bug-gnu-emacs@gnu.org; Sat, 01 Jun 2013 14:00:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uiq6H-0003Sz-6o for bug-gnu-emacs@gnu.org; Sat, 01 Jun 2013 14:00:22 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uiq6H-0003St-3a for bug-gnu-emacs@gnu.org; Sat, 01 Jun 2013 14:00:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Uiq7u-0001i2-GH for bug-gnu-emacs@gnu.org; Sat, 01 Jun 2013 14:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Copley Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Jun 2013 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14513 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14513-submit@debbugs.gnu.org id=B14513.13701097166559 (code B ref 14513); Sat, 01 Jun 2013 18:02:02 +0000 Original-Received: (at 14513) by debbugs.gnu.org; 1 Jun 2013 18:01:56 +0000 Original-Received: from localhost ([127.0.0.1]:46485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uiq7o-0001hj-0o for submit@debbugs.gnu.org; Sat, 01 Jun 2013 14:01:56 -0400 Original-Received: from mail-ee0-f50.google.com ([74.125.83.50]:61190) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uiq7j-0001hM-TJ for 14513@debbugs.gnu.org; Sat, 01 Jun 2013 14:01:53 -0400 Original-Received: by mail-ee0-f50.google.com with SMTP id c41so721182eek.37 for <14513@debbugs.gnu.org>; Sat, 01 Jun 2013 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=U9jCBPu9MZftBTQcylqHbVX3Oe62rQi2GE8TfhJ4g+A=; b=YsTPkcmdHSpDhY0m4p6ol2AdkHOYnGQw7sJBmbIMqG18UsgS1lQloKvExbps2VcWBS Bw5kE2P1QlS4YnRWdTSIyP7jdGL+zFtBK1GB2N/CY+xO3AaiScheM5dvLGKQqCOVe0ba ya2Ztkw0rgwMXeMb3qfTyxEV0GUvObYtX9JXSiS4nnFKCRiJg0mqgwtqRBSsPos5JTIc mQx2Ir8cNFjnCIkoXmlmZqrPJRfAuV804FWoS4XmZSDJzjCpCUO2b8plbHdxWvT6G+JA kBO9bPBmDtJrai6tBcD5UQO+VrQufxsdyNMQGo8k8O7s+qJJitsKMHZ436ZIYYqKVGLM 6D1A== X-Received: by 10.15.111.202 with SMTP id cj50mr17451331eeb.140.1370109603994; Sat, 01 Jun 2013 11:00:03 -0700 (PDT) Original-Received: by 10.14.212.67 with HTTP; Sat, 1 Jun 2013 11:00:03 -0700 (PDT) In-Reply-To: <8361xx20lb.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:74738 Archived-At: --089e01635502400dd304de1b80b9 Content-Type: text/plain; charset=ISO-8859-1 [Sorry, I dropped the list from the CC again.] On 1 June 2013 18:29, Eli Zaretskii wrote: > > Date: Sat, 1 Jun 2013 18:25:14 +0100 > > From: Richard Copley > > > > No I won't, sorry. I'd forgotten: that's not possible without resorting > to > > heuristics, because ${locallisppath} is potentially a ":"-separated path. > > Is it possible to support only the Windows style? That's the least we > can do, because the result _must_ be a Windows-style path, or else it > won't work, since Emacs is a native Windows executable. > That might be more logical than supporting only MSYS style. But note the result is a Windows-style path with the above patch, e.g. "--enable-locallisppath=/c/emacs/site-lisp" gives #define PATH_SITELOADSEARCH "c:/emacs/site-lisp" On 1 June 2013 18:38, Eli Zaretskii wrote: > > Date: Sat, 1 Jun 2013 18:25:14 +0100 > > From: Richard Copley > > > > > It does not, I'm afraid. I'll try and fix that, and send a replacement > > > patch. > > > > > > > No I won't, sorry. I'd forgotten: that's not possible without resorting > to > > heuristics, because ${locallisppath} is potentially a ":"-separated path. > > Btw, you need not resort to heuristics even if you don't know whether > ${locallisppath} is MSYS style or Windows style. You can rely on the > fact that MSYS transforms the path when it calls a native Windows > application. Here's an example, using cpp.exe, which is an > application you can rely on being available and on being a MinGW > executable: > > $ cpp -dM -Dfoo=/d/usr/bin:/c/windows < /dev/null | fgrep foo > #define foo d:\usr\bin;c:\windows > $ cpp -dM -Dfoo='d:/usr/bin;c:/windows' < /dev/null | fgrep foo > #define foo d:/usr/bin;c:/windows > > (You'd need to convert backslashes to forward slashes in the first > example, but that's easy, right?) > > The only requirement is that the argument to --locallisppath uses one > of the two styles consistently. But that is a reasonable requirement, > I think. > Interesting, thanks. I might have another patch later. --089e01635502400dd304de1b80b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[Sorry, I dropped the list from the CC again.]

On 1 June 2013 18:29, Eli Z= aretskii <eliz@gnu.org> wrote:
> Date: Sat, 1 Jun 201= 3 18:25:14 +0100
> From: Richard Copley <rcopley@= gmail.com>
>
> No I won't, sorry. I'd forgotten: that's= not possible without resorting to
> heuristics, because ${locallisppath} is potentially a ":"-se= parated path.

Is it possible to support only the Windows style? =A0That's the l= east we
can do, because the result _must_ be a Windows-style path, or else it
won't work, since Emacs is a native Windows executable.

That might be more = logical than supporting only MSYS style.
But note the result is a Window= s-style path with the above patch, e.g.
=A0=A0=A0 "--enable-localli= sppath=3D/c/emacs/site-lisp"
gives
=A0=A0=A0 #define PATH_SITELOADSEARCH "c:/emacs/site-lisp&quo= t;

On 1 June 2013= 18:38, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Sat, 1 Jun 201= 3 18:25:14 +0100
> From: Richard Copley <rcopley@= gmail.com>
>
> > It does not, I'm afraid. I'll try and f= ix that, and send a replacement
> > patch.
> >
>
> No I won't, sorry. I'd forgotten: that's not possible with= out resorting to
> heuristics, because ${locallisppath} is potentially a ":"-se= parated path.

Btw, you need not resort to heuristics even if you don't know whe= ther
${locallisppath} is MSYS style or Windows style. =A0You can rely on the
fact that MSYS transforms the path when it calls a native Windows
application. =A0Here's an example, using cpp.exe, which is an
application you can rely on being available and on being a MinGW
executable:

=A0 $ cpp -dM -Dfoo=3D/d/usr/bin:/c/windows < /dev/null | fgrep foo
=A0 #define foo d:\usr\bin;c:\windows
=A0 $ cpp -dM -Dfoo=3D'd:/usr/bin;c:/windows' < /dev/null | fgre= p foo
=A0 #define foo d:/usr/bin;c:/windows

(You'd need to convert backslashes to forward slashes in the first
example, but that's easy, right?)

The only requirement is that the argument to --locallisppath uses one
of the two styles consistently. =A0But that is a reasonable requirement, I think.

Interesting, thanks= .
I might have another patch later.
=

--089e01635502400dd304de1b80b9--