[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41242: Port feature/native-comp to Windows
From: |
Eli Zaretskii |
Subject: |
bug#41242: Port feature/native-comp to Windows |
Date: |
Sat, 16 May 2020 09:22:11 +0300 |
> 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.
- bug#41242: Port feature/native-comp to Windows, (continued)
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/15
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/15
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/15
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/15
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/15
- bug#41242: Port feature/native-comp to Windows,
Eli Zaretskii <=
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/16
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/16
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/16
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/16
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/16
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/16
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/19
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/19
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/20