[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: |
Wed, 20 May 2020 16:06:46 +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: Tue, 19 May 2020 16:25:53 -0300
>> Cc: Andrea Corallo <akrl@sdf.org>, 41242@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@sdf.org
- bug#41242: Port feature/native-comp to Windows, (continued)
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/25
- bug#41242: Port feature/native-comp to Windows, Richard Stallman, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/23
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/23
- bug#41242: Port feature/native-comp to Windows,
Andrea Corallo <=
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/20
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/20