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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: nicolasbertolo <at> gmail.com, 41242 <at> debbugs.gnu.org
Subject: Re: bug#41242: Port feature/native-comp to Windows
Date: Sat, 23 May 2020 15:20:06 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: nicolasbertolo <at> gmail.com, 41242 <at> debbugs.gnu.org
> Date: Sat, 23 May 2020 11:21:03 +0000
> 
> >> BTW reloading from dump the "dumped" eln are not located by searching in
> >> the load-path for all suffix.  The eln position is stored into the
> >> compilation unit object for performance reasons.
> >
> > Are you saying we store the absolute file name of the .eln files in
> > the pdumper file?  If so, how can Emacs start up if the .eln files
> > were moved to another location, e.g. as part of "make install", or
> > more generally if Emacs was relocated since it was dumped?
> 
> To be precise we store the relative path of the .eln from the emacs
> executable, both for the local build both for the file position we will
> have after a "make install".
> 
> Reloading the first compilation unit the code detect in which of this
> two cases we are (this is where file-exists is called) and this
> information is used for all the following compilaiton unit to be
> revived.

Do we indeed have only 2 use cases regarding the relative file name of
.eln files, and not more?

Previous Next

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