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

[Nicolas Bértolo]

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

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 can think of two ways:

- The whole system will have the mingw libraries available in the LoadLibrary()
search path.

- The mingw distribution comes with many utilities that the user may not want in
  PATH. I haven't explicitly installed any of these, but they are in the same
  folder as `gcc`: ImageMagick, Python, sqlite, TCL.

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

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.

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

Nicolas