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

[Eli Zaretskii]

> Date: Tue, 10 Dec 2013 21:09:14 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> I think that the function 'unmsys--file-name' is conceptually wrong, because:
> 
> 1. It assumes that every MSYS path will match the "/c/foo/bar"

It does nothing of the kind.  It handles _only_ those file names that
slip into Emacs in the /c/foo/bar form, which Emacs cannot handle.

> pattern, which in general is false (as we've already seen).

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.

> 2. Some directory "c:/whatever" could be mounted in MSYS as "/c/foo",
> and therefore "/c/foo/bar" should be translated as "c:/whatever/bar"
> (not "c:/foo/bar"). Improbable but possible.

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.

> Therefore, like I've said before, IMO this is unreliable, and we
> should translate (or "unmsys") _all_ MSYS paths with the 'msys-to-w32'
> script.

Which is also unreliable, as we've seen.

There are no bullet-proof solutions with MSYS.  Building Posix
packages on Windows is inherently fragile, and always will be.
Therefore, the solutions should be the simplest ones we can find that
do the job.  People who do unreasonable things should be told not to.