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

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (text/plain, inline)]

> 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 <at> gnu.org>) escribió:

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

[Message part 2 (text/html, inline)]

Previous Next

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