bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrea Corallo
Subject: bug#41242: Port feature/native-comp to Windows
Date: Sat, 16 May 2020 07:12:47 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

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

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@sdf.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]