|
From: | Richard Copley |
Subject: | bug#14513: 24.3.50; Site load-path pieces differ in MSYS build |
Date: | Sat, 1 Jun 2013 19:00:03 +0100 |
> Date: Sat, 1 Jun 2013 18:25:14 +0100
> From: Richard Copley <rcopley@gmail.com>
>
> No I won't, sorry. I'd forgotten: that's not possible without resorting toIs it possible to support only the Windows style? That's the least we
> heuristics, because ${locallisppath} is potentially a ":"-separated path.
can do, because the result _must_ be a Windows-style path, or else it
won't work, since Emacs is a native Windows executable.
> Date: Sat, 1 Jun 2013 18:25:14 +0100
> From: Richard Copley <rcopley@gmail.com>
>
> > It does not, I'm afraid. I'll try and fix that, and send a replacementBtw, you need not resort to heuristics even if you don't know whether
> > patch.
> >
>
> No I won't, sorry. I'd forgotten: that's not possible without resorting to
> heuristics, because ${locallisppath} is potentially a ":"-separated path.
${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.
[Prev in Thread] | Current Thread | [Next in Thread] |