GNU bug report logs - #41242
Port feature/native-comp to Windows

Previous Next

Full log

View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nicolas Bértolo <nicolasbertolo <at> gmail.com>, 41242 <at> debbugs.gnu.org
Subject: bug#41242: Port feature/native-comp to Windows
Date: Sat, 16 May 2020 07:12:47 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
>> Date: Fri, 15 May 2020 16:44:04 -0300
>> Cc: Andrea Corallo <akrl <at> sdf.org>, 41242 <at> 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?

IIUC the complication of package.el that makes it different from the
general cases you have described is that the eln-... sub-directory
has to be removed to be able to clean-up entirely the package.

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

-- 
akrl <at> sdf.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.