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

[Dani Moncayo]

On Wed, Dec 11, 2013 at 6:12 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 10 Dec 2013 21:57:04 +0100
>> From: Dani Moncayo <dmoncayo@gmail.com>
>>
>> I think that it would be possible that the path to "unmsys" had the
>> form "/foo/bar".  For example if someone has the source code tree
>> under his MSYS tree and invokes the configure script with an absolute
>> MSYS path (e.g. "/home/user/emacs/trunk/configure").
>>
>> 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.

I've myself reproduced the problem this morning (visit the attached
file "bootstrap1.log" and look there for "unmsys" - you'll see the
problem clearly).

>> > Not sure what you meant here.  If you mean your use case of building
>> > inside the MSYS tree, then that one should be (and was) handled by
>> > different means.
>>
>> It was handled in one place (for generating the native paths in
>> 'src/epaths.h'), but it seems that there are more places where a
>> translation to native w32 format is performed, and it would be nice if
>> that translation was as reliable as possible.
>
> Does it make any trouble?  If so, please report the details (and I
> still don't understand how it works for you, since that's exactly what
> you do).

This is answered above.  Again: the problem arises with _absolute_
MSYS path which don't match the "/c/foo/bar" pattern.

> If we have no specific problems, let's leave this alone, since it is
> not broken.  Our aim is not to translate file names, or aim is to
> build Emacs reliably and correctly.

Indeed, that is our aim, and for that reason I'd like to make the MSYS
build procedure more reliable/robust than is right now, and I think I
know how to do it (see below).

>> I agree that the MSYS shell auto-conversion of paths can be tricky,
>> but we still don't know the origin of this problem.
>
> What problem are you talking about?  The lack of auto-conversion?  Its
> origin is well known: MSYS simply tries to play it safe, and doesn't
> auto-convert unless it is absolutely sure it sees a file name.

Well, I've been reading a bit about the rules used by the MSYS bash
for auto-translating posix-type PATHS to Windows native paths [1], and
I think I now understand the problem.

Ideally, the MSYS bash should be smart enough to correctly translate
paths as needed when invoking native w32 programs, but the behavior is
not always what we want.  For example, in 'lisp/Makefile.in' we have:

 custom-deps: doit
    $(setwins_almost); \
    echo Directories: $$wins; \
    $(emacs) -l cus-dep \
     --eval '(setq generated-custom-dependencies-file
(unmsys--file-name "$(srcdir)/cus-load.el"))' \
     -f custom-make-dependencies $$wins

You had to try to manually translate the path "$(srcdir)/cus-load.el"
with 'unmsys--file-name' because the MSYS bash didn't do it
automatically as expected (if the path was a standalone argument, it
would have been translated as expected, but the path is part of a more
complex argument, and MSYS doesn't handle that case well.).

But your way of implementing the translation doesn't work with all
types of MSYS paths, as we've already seen.

After doing some test, I've got a path that seems to fix this problem
(see "patch.v3.diff" attached).

The file "bootstrap2.log" is the output of my "make bootstrap" with
the patch applied.  You can compare it with "bootstrap1.log" to see
how the problems are indeed fixed.

If you think it is correct, I may commit it to the trunk.

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)

-- 
Dani Moncayo

[1] http://www.mingw.org/wiki/Posix_path_conversion

files.zip
Description: Zip archive