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

[Nicolas Bértolo]

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

True, right now the .eln would not be removed. Not even in Posix.

Therefore it will continue to be loaded unless `load-prefer-newer` is true.

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

Help me understand. Are you referring to the case where a developer changes

an .el file for which an .eln file (now outdated) already exists? I think fixing the

case above will fix this one.

El sáb., 16 may. 2020 a las 3:22, Eli Zaretskii (<eliz@gnu.org>) escribió:

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