RE: Patch for Build under MSW + MSYS2

Answering to myself...
> 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.
From the top of my head, I sort of remember having read somewhere that
DOS short names should be fled like plague. Anyway, long names would be
OK, as if you use the Makefile variable within a Lisp string, then
spaces are OK --- well, if there are several consecutive spaces then
autotools would need to write the Makefile variable like this:
abs_builddir_w=c:/Some/Path$(SPACE)$(SPACE)with/two/consecutive/spaces
EMPTY:=#
SPACE:=$(EMPTY) #
Another way would be for autotools to check that there are no spaces in
the MSWindows absolute path for build dir (they do this check for the
MSYS path, but I am not sure that they do it also for the corresponding
cygpath -w path).
Another point is that backward slash would be also OK if escaped, so
what we should discuss with Autotools people is provision of some
Makefile variable for absolute build dir path with :
1) proper handling of spaces in one of the following ways:
   1.1 use of short names
   1.2 $(SPACE)$(SPACE) for consecutive spaces
   1.3 check no space in MSW abspath
2) proper handling of backslash for stringization in one of the
   following ways
   1.1 use of forward slashes
   1.2 escaping \ by \\ for stringization.

OK, what I propose is that you take my patch as it is, and we continue
this discussion on some autotools forum (I really doubt that Emacs
people would ever accept to have some --setq-path CLI interface just for
the sake of MSYS tricks to work properly, but if you think that it is a
good idea, I can try this too).
  Vincent.


________________________________
De : bbdb-user <[email protected]> de la part de Vincent Belaïche <[email protected]>
Envoyé : dimanche 11 février 2018 01:07:22
À : Roland Winkler
Cc : [email protected]
Objet : 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")'
by
 --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.


________________________________
De : Roland Winkler <[email protected]>
Envoyé : vendredi 9 février 2018 23:01:10
À : Vincent Belaïche
Cc : [email protected]
Objet : RE: Patch for Build under MSW + MSYS2

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?