>> >> In that case, 'unmsys--file-name' will not translate the MSYS path
>> >> ("/home/user/...") as expected.
>> >
>> > How is this different from your use case, which is already handled?
>>
>> The difference is this:  I invoke the configure script (from the build
>> dir) using a relative path, which works with the current trunk.  But
>> if someone invokes the configure script using an absolute path which
>> doesn't match the "/c/foo/bar" pattern (e.g.
>> "/home/user-foo/emacs/trunk/configure"), the build will fail.
>
> The "pwd -W" method worked with both.  I understand that the
> msys-to-w32 method broke that.

No, the msys-to-w32 method didn't broke that.  It was at revno 114990
(which is not mine, BTW).

> Then please un-break it.

The attached patch seems to be what you want (I've tested it and works fine).

>> But your way of implementing the translation doesn't work with all
>> types of MSYS paths, as we've already seen.
>
> It isn't supposed to.
>
>> PS: The only "tricky" part of the patch is this:
>>
>>   leimdir=`${srcdir}/../build-aux/msys-to-w32 "${leimdir}"` && \
>>   ${RUN_EMACS} -l international/quail \
>>     --eval "(update-leim-list-file \"$${leimdir}\");"
>>                                                    ^
>>                                                    ^
>>                                                    ^
>> This semicolon does not alter the effect of the lisp expression, but
>> prevents MSYS from altering the argument, since such argument (in the
>> MSYS case) will have a colon ("c:/foo/bar") and that would make MSYS
>> think about it as a list of posix paths which need translation to
>> native windows format.  See the rules in [1].  (This technique has
>> been employed in several points)
>
> I don't think we should rely on such fragility.

Ok, I agree that it is fragile.

I don't like the current approach either, but it seems better that the
above one, yes.

So I'll wait for you to validate the attached patch.

-- 
Dani Moncayo