[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.