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

[Eli Zaretskii <eliz@gnu.org>]

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

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

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.

> > People also shoot themselves in the foot, but why should we cater to
> > suicidal ones?  "If it hurts, don't do that."  MSYS is a tool to build
> > Posix packages, it has no purpose other than that.  So it makes very
> > little sense to configure MSYS in a way that interferes with its main
> > purpose.  People could do that by mistake, of course, but then the
> > solution is to recognize the mistake and correct it.
> 
> Well yes, this second problem is minor, but we could fix it with the
> same effort.

It is not a problem at all, and therefore isn't worth wasting time and
energy.

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