[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16099: 24.3.50; Build failure, undefined function `cl-member'
From: |
Eli Zaretskii |
Subject: |
bug#16099: 24.3.50; Build failure, undefined function `cl-member' |
Date: |
Thu, 12 Dec 2013 18:33:43 +0200 |
> 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.
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', (continued)
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Glenn Morris, 2013/12/10
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Glenn Morris, 2013/12/10
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Eli Zaretskii, 2013/12/10
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Dani Moncayo, 2013/12/10
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Eli Zaretskii, 2013/12/10
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Dani Moncayo, 2013/12/10
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Eli Zaretskii, 2013/12/11
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Dani Moncayo, 2013/12/12
- bug#16099: 24.3.50; Build failure, undefined function `cl-member',
Eli Zaretskii <=
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Dani Moncayo, 2013/12/12
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Dani Moncayo, 2013/12/14
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Eli Zaretskii, 2013/12/14
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Glenn Morris, 2013/12/14
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Dani Moncayo, 2013/12/14
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Glenn Morris, 2013/12/14
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Dani Moncayo, 2013/12/14
- bug#16099: 24.3.50; Build failure, undefined function `cl-member', Eli Zaretskii, 2013/12/10
- bug#16099: closed (Re: bug#16099: 24.3.50; Build failure, undefined function `cl-member'), Eli Zaretskii, 2013/12/10