Re: New msys-to-w32 breaks using %emacs_dir%, @VER@ in locallisppath

[Dani Moncayo]

>> Agreed.  The directories you specify with --enable-locallisppath don't
>> have to exist at build time.  That is why, in the "epaths-force-w32"
>> target, the translation of "${locallisppath}" is done by passing "N"
>> to the argument MUSTEXIST of the msys-to-w32 script.
>
> Then why did it complain about %emacs_dir%/share/emacs/@VER@/site-lisp
> ? It does not contain any colon.

Because the script didn't know how to translate such a path.  (now it
does: the translations of that kind of paths are literally the
original ones).

But aside from that exception that was introduced yesterday, all
translations performed by the script are ultimately based on "cd"ing
to an _existing_ directory (the one received as parameter, if it
exists, or else the deepest existing directory among its parents) and
then using "pwd -W" to get its translation (if some trailing
directories were discarded, they are concatenated to the translation
to from the final translation).

I designed the script that way, because I think it's the only reliable
way of doing the job. Imagine for example that "c:/foo" is mounted in
MSYS as "/c/bar".  Then the translation of "/c/bar/emacs" should be
"c:/foo/emacs" (not "c:/bar/emacs").  IOW, I wanted to completely
avoid the pattern-matching approach, and base all translations on the
"pwd -W" feature of the MSYS bash shell.

>> Conclusion: always use MSYS-style paths ("/c/mydir") instead of
>> windows native paths ("c:/mydir") when specifying paths with
>> --enable-locallisppath, because the colon ":" will be used as
>> separator in the path list.
>
> I used c:/mydir as an example. What I mean is,
> --enable-locallisppath=/c/mydir should not complain. I haven't checked
> that it does, but if not, I'm puzzled that it complained about the
> %emacs_dir% path.

"--enable-locallisppath=/c/mydir" should work fine.  See above.


-- 
Dani Moncayo