Re: [PATCH] [WIP] Port feature/native-comp to Windows.

[Eli Zaretskii <eliz@gnu.org>]

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Mon, 11 May 2020 12:20:36 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, emacs-devel@gnu.org
> 
> > I don't think it would be wise for us to distribute libgccjit, because
> > then we'd need to distribute the GCC sources, and the user will be
> > unable to reliably use the shipped libgccjit with their local GCC
> > installation (due to possible version mismatch).
> 
> IMHO that is really inconvenient from the point of view of a user that just
> wants to install Emacs and use all its features.

Not "all" of its features, just one.

And yes, this is an inconvenience, but it isn't specific to
MS-Windows.  AFAIK, Posix systems nowadays come without a compiler
preinstalled, and you need to install it if you want that.

This is a price to pay for compiling to native code using an external
compiler.  there's no way around this, I think.  People who cannot
afford installing a working compiler and Binutils will have to give up
compiling Lisp files to native code (the Lisp files that come with
Emacs can still be provided as *.eln, I would hope).

> Installing Mingw is not a simple process (at least in my experience). And adding
> it to PATH will also add many other unrelated utilities. This pollutes the PATH
> variable and may cause trouble. I haven't done in my machine because I fear it
> may interact with badly with the rest of the system.

I do have GCC and Binutils on PATH, and I have yet to see any problem.
But of course, someone else might feel uncomfortable with that.

> I can think of two ways:
> 
> - The whole system will have the mingw libraries available in the LoadLibrary()
> search path.

Why is that a problem?  The number of DLLs is quite small and their
names don't conflict with Windows system DLLs.

> - The mingw distribution comes with many utilities that the user may not want in
>   PATH.

I don't think I understand what utilities you have in mind.  Please
name them.

> I haven't explicitly installed any of these, but they are in the same
>   folder as `gcc`: ImageMagick, Python, sqlite, TCL.

I don't know why you have them or which package they came with, but
they are definitely not needed for running the compiler to produce
programs.

> Overall I don't think it is a good idea to make the user install a whole Mingw
> distribution when they only need 10 files.

I really don't see any way around this, sorry.

> I can think of a middle-ground solution. Let's have a `comp-gcc-path` variable
> that is prepended to PATH in `process-environment` when launching the
> compilation subprocess. This will variable should point to the path
> where `gcc` lives.
> In my system it would be "C:/msys64/mingw64/bin".
> 
> This would set up the environment libgccjit expects (no "-B" flag necessary),
> but it would not require adding that directory to PATH. It separates what is
> necessary for Emacs to work, from the environment the user setup to work.

This only solves the problem of having the stuff on PATH, it doesn't
solve the problem of installing it.  And it creates a new problem: the
DLLs will not be in a place where the system looks for them, so we
will need some extra code in the *.eln loader to find them.

> As an example: imagine the user prepends a "C:/myproject/custom-gcc/bin" to PATH
> and then starts Emacs because they need a customized GCC to work on a certain
> project. Let's say they need a custom libgccjit for that project too. Emacs
> would load that version because it is first in PATH, and then what may happen is
> unpredictable. It may have different function signatures and when Emacs calls
> them through dlsym() we would get a hard-to-find crash.

This can happen even without this.  Users who have more than one
compiler installation need to be very careful and need to know what
they are doing.

> > Right, I think at least on MS-Windows we need to do that.  On Posix
> > platforms, Emacs will be able to start if there's no libgccjit (and
> > will crash if it attempts to call any of its functions), so it might
> > be a good idea to use dlopen/dlsym there as well.  But on Windows it
> > is IMO critical.
> 
> I will do this.

Thanks.