bug#16099: 24.3.50; Build failure, undefined function `cl-member'

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 12 Dec 2013 15:08:08 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 16099@debbugs.gnu.org
> 
> >> 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.  Then please un-break it.

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