[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#75812: 29.2.50; Support native-compiling package-install from batch
From: |
Eli Zaretskii |
Subject: |
bug#75812: 29.2.50; Support native-compiling package-install from batch Emacs |
Date: |
Wed, 30 Apr 2025 08:49:21 +0300 |
> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: acorallo@gnu.org, app-emacs-dev@janestreet.com,
> stefankangas@gmail.com, 75812@debbugs.gnu.org, shipmints@gmail.com
> Date: Tue, 29 Apr 2025 15:28:11 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> (defun native-comp-async-wait-for-all-done ()
> >> (unless (zerop (comp--async-runnings))
> >> (catch 'native-comp-done
> >> (let ((native-comp-async-all-done-hook (list (lambda () (throw
> >> 'native-comp-done)))))
> >> (while (sit-for 999))))))
> >>
> >> Could we add that?
> >
> > Why do we need to add it? Can't you just use it in your code?
>
> Since others in this thread have said they would like to be able to wait
> monitor the completion of native compilation. It seems like it would be
> good to have a high quality implementation be part of Emacs. (and
> frankly, I don't think throwing out of a hook as a means of control flow
> is a good idea, and I'd like to do something better than that)
I'm not sure we can come up with a general enough function for this
purpose, because what the caller wants to do while waiting will differ
from application to application. In the above case the caller just
waits, but that's not necessarily what everyone will want to do.
So if you want to propose a general-purpose function, we need more
thorough design and a better abstraction, IMO. Without that, the
above is just a thin wrapper around an existing hook.
> >> Would it be reasonable to merge those directories into the last entry of
> >> native-comp-eln-load-path? (e.g. /usr/lib/emacs/30.1.50/native-lisp)
> >
> > No! The last directory is in many cases not writable by users, and it
> > includes preloaded files, see the doc string of the variable. The
> > last directory should be left alone. Instead, add another directory
> > to the default value, between the user's eln-cache and the last
> > member, and have your local packages' *.eln files there.
>
> I'm doing this package precompilation at Emacs build time, and the last
> directory is writable at that time. After installation, of course, it
> is not writable, but that doesn't matter since only these precompiled
> package .elns are going to be written there.
>
> In general, I have site-lisp that is byte-compiled and native-compiled,
> and it seems like the right place to write .eln files for site-lisp is
> the last directory on native-comp-eln-load-path. After all, site-lisp
> is effectively bundled with Emacs, set up at install time just like core
> Elisp. Is there some issue with doing that?
You are invalidating the assumption that the last directory is special
in that it holds the results of compiling the Lisp files that are
bundled with Emacs. You asked me whether this can be done, and my
warm recommendation is not to do that. You can do whatever you want
regardless, of course, but then please don't come back reporting what
you think is a bug which was caused by that, because placing other
*.eln files in that directory is not supported.