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

Previous Next

Full log

Message #164 received at 41242 <at> debbugs.gnu.org (full text, mbox):

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

> From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
> Date: Sat, 16 May 2020 13:12:20 -0300
> Cc: Andrea Corallo <akrl <at> sdf.org>, 41242 <at> debbugs.gnu.org
> 
> > 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.

No, on Posix systems we can delete the file, and it will be actually
deleted when its last handle is closed.  I believe this works with
shared libraries as well.

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

No, I mean building Emacs with "make -j10 bootstrap".

> I think fixing the case above will fix this one.

It's the same problem, yes.  Just a slightly different use case, which
could therefore have different probabilities for some aspects.  For
example, the probability of the same .el file being recompiled from
two separate sessions is relatively small, except when you consider
the "make -jN" use case.

Previous Next

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