bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14513: 24.3.50; Site load-path pieces differ in MSYS build


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

[Sorry, I dropped the list from the CC again.]

On 1 June 2013 18:29, Eli Zaretskii <address@hidden> wrote:
> Date: Sat, 1 Jun 2013 18:25:14 +0100
> From: Richard Copley <address@hidden>
>
> 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 <address@hidden> wrote:
> Date: Sat, 1 Jun 2013 18:25:14 +0100
> From: Richard Copley <address@hidden>
>
> > 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]