RE: Patch for Build under MSW + MSYS2

Dear Roland,

Here are the answers to the two points that you raise:

> - Why is it necessary in a cygwin environment to call cygpath at
> this place?

Because Emacs is a native application not an MSYS
application. Considering a similar example to that of my previous email,
Emacs does not have any knowledge of this that
/usr/local/lisp/loaddefs.el is in reality
C:\Programmes\msys64\usr\local\lisp\loaddefs.el

MSYS has some euristic, so that if /usr/local/lisp/loaddefs.el was a
stand-alone argument, then MSYS would change this argument to
C:\Programmes\msys64\usr\local\lisp\loaddefs.el just before calling
Emacs, but here, /usr/local/lisp/loaddefs.el is not a stand-alone
argument, it is hidden to MSYS within some Lisp _expression_ like that:

--eval '(setq generated-autoload-file "/usr/local/lisp/loaddefs.el")'

When MSYS sees this, it sees two arguments, the first one is --eval, and
the second one is the full string starting with ( and ending with
). None of theses two arguments looks like a path, so MSYS does not play
its euristic substitution trick.

There would be a solution without autotools ticks if Emacs had a command
line option --setq-path such that

--setq-path xxxx yyyy

would be equivalent to

--eval '(setq XXXX "YYYY")'

where XXXX and YYYY are the same as xxxx and yyyy respectively, except
for any shell/elisp escaping (e.g. if yyyy is « 'a\b\c' » , then YYYY is
« a\\b\\c », or if xxxx is « "a'" », then XXXX is « a\'"'"' ».

with such a command line option one could just replace

--eval '(setq generated-autoload-file "/usr/local/lisp/loaddefs.el")'

--setq-path generated-autoload-file /usr/local/lisp/loaddefs.el

and it would work fine under MSYS without any need of cygpath.

> - Why is cygpath not enough for generating lisp code?

The only macro provided by autotools is CYGPATH_W which is equivalent to
calling command cygpath with option -w.

Actually cygpath also has an option -m which use regular slashes instead
of backslashes, but autotools do not have the CYGPATH_M macro. If it had
it, then the stringification would be simplified, because there would
not be any need for the pipe to sed.

Maybe autotools people considered that the -w option was more portable
than the -m one.

In fact, it would be better if the autotools were providing some
variable abs_builddir_w where the /usr conversion to
c:/Programmes/msys64/usr is already done, there are forward slashes, and
short names (no spaces) are used. So you would just use abs_builddir_w
in the Makefile.am. That would however need to run cygpath with option
-md (-m means forward slashed, and -d means short names). So I don't
know it would be portable enough in Autotools' people opinion.

Vincent.

PS : Attached is the revised patch.

On Thu Feb 8 2018 Vincent Belaïche wrote:
> The CYGPATH_W variable is provided by autotools whathever the platform,
> but on all *nixy system that just does an echo.
> On MSWindows it converts the abolute path from the MSYS/Cygwin mount to
> the real MSWindows file system, for instance /usr/local/bin can be
> converted to C:\Programmes\msys64\usr\local\bin --- well actually you
> cannot guess without calling the cygpath command, it depends how
> Cygwin/Msys2 was installed.
> Concerning the second comment I can send another patch with the
> simplified as much as possible way:
>
> abs_target=`$(CYGPATH_W) $(abs_builddir)/$@ | sed 's/\$[\\]\$/\\\\\\1/g'`; \
>
> Please note that it cannot be simplified further : I still need the pipe
> to sed command because cygwin -w use the \ filename separator, so that
> needs to be elisp-string escaped.

Thanks, I see. Can you please include comments in your patch
explaining briefly these two things (in the context of your patch)?

- Why is it necessary in a cygwin environment to call cygpath at
this place?

- Why is cygpath not enough for generating lisp code?

From:	Vincent Belaïche
Subject:	RE: Patch for Build under MSW + MSYS2
Date:	Sun, 11 Feb 2018 00:07:22 +0000