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

From: Richard Copley <[email-masked]>
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 <[email-masked]> wrote:

> > Date: Sat, 1 Jun 2013 18:25:14 +0100
> > From: Richard Copley <[email-masked]>
> >
> > 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 <[email-masked]> wrote:

> > Date: Sat, 1 Jun 2013 18:25:14 +0100
> > From: Richard Copley <[email-masked]>
> >
> > > 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.