bug#41242: Port feature/native-comp to Windows

[Eli Zaretskii]

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Fri, 15 May 2020 16:44:04 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
> 
> To summarize:
> 
> The best idea seems to be to rename the .eln file when removing the package or
> recompiling. We need to reach a consensus on where to put the old .eln file,
> though.
> 
> There are two options:
> 
> - Put it in the same folder as the original .eln file. This means that
>   `package-delete` will not be able to delete the directory. Additionally, it
>   will be tricky to handle left over files from an instance of Emacs that
>   crashes.
> 
> - Another option is to move them to `package-user-dir`. This option means that
>   `package-delete` will be able to delete the directory.
> 
> What option do you prefer?

I'm not sure I understand why we are talking only about package.el.
Wouldn't the same problem happen if the user recompiles a .el file for
which a .eln file already exists and is loaded into the session?  And
similarly when Emacs is being built and all the *.el files are being
compiled or recompiled, sometimes by several Emacs processes running
in parallel via "make -jN"?

I think the solution should handle all of these use cases, not just
that of package.el upgrading a package.  Do you agree?

> - `package-delete` iterates over the .eln files in the package directory. It
>   tries to delete it, if it fails it is moved to somewhere (see point above).
> 
> - When Emacs GCs a native compilation unit it should check if it has been
>   renamed (need to check if GetModuleFileNameA is fit for this). If it has, it
>   tries to delete it. If it fails, then some other Emacs instance must be 
> using
>   it.
> 
> - The last step before calling exit() should FreeLibrary() all remaining .eln
>   files and run the equivalent of `rm $package_user_dir/*.eln.old`.

Sounds OK to me, I don't think we came up with anything better during
the discussion till now.