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

Previous Next

Full log

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

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: Re: bug#41242: Port feature/native-comp to Windows
Date: Wed, 20 May 2020 16:06:46 +0000

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

>> From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
>> Date: Tue, 19 May 2020 16:25:53 -0300
>> Cc: Andrea Corallo <akrl <at> sdf.org>, 41242 <at> debbugs.gnu.org
>> 
>> * lisp/emacs-lisp/comp.el (comp-effective-async-max-jobs): Use
>> NUMBER_OF_PROCESSORS environment variable if system is Windows NT,
>> "nproc" if it is in PATH or a default of 1.
>
> This shouldn't be necessary: we already have a function to determine
> the number of processors, see get_native_system_info in w32.c.  If you
> need the result exported to Lisp, we can define a new variable which
> will be populated with the value.
>
>> Subject: [PATCH] Determine the emacs root dir only when necessary.
>> 
>> * src/fileio.c: Introduce function emacs_root_dir(). Refactor
>> `expand-file-name` to use it.
>> * src/lisp.h: Separate emacs_root_dir() into dos_emacs_root_dir() and
>> w32_emacs_root_dir().
>> * src/msdos.c: Rename emacs_root_dir() to dos_emacs_root_dir().
>> * src/w32.c: Rename emacs_root_dir() to w32_emacs_root_dir().
>
> Can you explain what problem this solves, and how?  It is especially
> important to understand when will be emacs_root_dir first called
> during a session.  That's because it calls filename_from_ansi, which
> AFAIR needs some setup that happens at the beginning of a session.

I'm not into what is happening on Windows and why is working differently
than Posix, but I can add this as a context:

While we are restarting from dump to reload the native compilation unit
in dump_do_dump_relocation we are calling Ffile_exists_p
(pdumper.c:5307) and this is calling Fexpand_file_name.

We need to do that because we need the eln file to revive the
compilation unit object.  Perhaps another way would be to use something
alternative to Ffile_exists_p?

But I've a question: is this a problem of Fexpand_file_name not working
correctly because something not initialized or a behavior we are trying
to change?

  Andrea

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