GNU bug report logs - #16099
MinGW build failure when srcdir is absolute and has "wrong" format

Previous Next

Full log

View this message in rfc822 format

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16099 <at> debbugs.gnu.org
Subject: bug#16099: 24.3.50; Build failure, undefined function `cl-member'
Date: Thu, 12 Dec 2013 20:53:29 +0100

[Message part 1 (text/plain, inline)]

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

[tmp.diff (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.