bug#45303: #45303 [feature/native-comp] building error on Windows

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Mon 21 Dec 2020, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>
>> Pal Gloss <pcfeb0009@gmx.com> writes:
>>
>>>> There are still problems related to the usage of Fdirectory_files and
>>>> internal_condition_case_5 I think. At least, I get a crash after the
>>>> bootstrap is dumped (? see attached build log)
>>>>
>>>> Debugger entered--Lisp error: (wrong-type-argument wholenump t)
>>>
>>> Despite 2526032ea954671aa48a6ad6d924df2941a8364a, this error still happens:
>>> Qt and Qnil should be swapped (see sed script at the bottom of the mail
>>> inside my build commands or the git diff in the build log).
>>
>> Hi Pal thanks for trying.
>>
>> I don't like to run or decript scripts, I like to review and apply
>> patches from contributors, why don't you submit one for this? :)
>
> The fix needed here is another tweak to eln_load_path_final_clean_up:
> the arguments for internal_condition_case_5 should end "Qnil, Qt,
> return_nil". After fixing that then a bootstrap build completes without
> crashes.

I'm sorry this week I'm rather busy progressing on new features plus I
cannot test Windows patches and this makes it very time consuming.

As I've said more then once on this thread: patches are welcome.

> Other issues noted when running the uninstalled emacs from build dir:

I think these are off topic for this thread but quickly:

> a) The ELN compile step is very slow during bootstrap.

On my machine make bootstrap is ~2.5x slower than vanilla build.

> b) The built emacs will run uninstalled (i.e. directly from the build
>    tree), but is almost unusable as the async ELN compile make emacs
>    very unresponsive to input.

You can customize `comp-async-jobs-number'.
<http://akrl.sdf.org/gccemacs.html#org73a9089>
The default works well on most systems but probably is not optimal for
your machine.

> c) The .eln files for a few core .el files are built in:
>      <builddir>/native-lisp/<version>-<target>-<hash>/*.eln
>
>    The async compile puts .eln files in:
>      $HOME/.emacs.d/eln-cache/<version>-<target>-<hash>/*.eln
>
>    Q1: Why are the compiled files not added to builddir/lisp-native ?
>    Q2: Why are the directory and filenames so long ?
>    Q3: Why are the directory names different ?

<https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg02186.html>
<http://akrl.sdf.org/gccemacs.html#org71a8de5>

>    This needs a heirarchy of files named after a hash of their content.
>    This problem has been solved by git, mercurial etc, and it would be
>    better to use a similar layout, and learn lessons from those tools
>    for how to do so efficiently.

Are you asking at the same time how the current system works and
suggesting how it should?

>    Q4: Why are the lisp files not *all* precompiled as part of the
>    build ?

make bootstrap NATIVE_FULL_AOT=1

<http://akrl.sdf.org/gccemacs.html#orgdb45946>
<http://akrl.sdf.org/gccemacs.html#orga0c267d>

>    Q5: What can be done to improve the slow compile time ?

I've never had the time to optimize the Lisp side of the compiler, last
week I did some profiling and made an idea on where and how to take
action.  I'll be on that in the new year, the current one has been
mostly on debug and integration.

>    Q6: Why are the built files so large ?

If you want a more compact representation of the code byte-code is
probably a better format than native code.

  Andrea