From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#55305: 28.0.50: With async nativecomp, package manager fails to load hyperbole-autoloads.el before compilation Date: Mon, 16 May 2022 19:57:00 +0300 Message-ID: <83k0aliffn.fsf@gnu.org> References: <83czgekby6.fsf@gnu.org> <83bkvykbpx.fsf@gnu.org> <83a6bik9vi.fsf@gnu.org> <8335hajjiy.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35013"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rsw@gnu.org, rswgnu@gmail.com, 55305@debbugs.gnu.org, akrl@sdf.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 16 19:40:53 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nqeiB-0008r0-9E for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 May 2022 19:40:51 +0200 Original-Received: from localhost ([::1]:37428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nqei5-0004co-JS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 May 2022 13:40:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqe2l-00060s-EB for bug-gnu-emacs@gnu.org; Mon, 16 May 2022 12:58:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:32794) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nqe2k-0005UZ-KB for bug-gnu-emacs@gnu.org; Mon, 16 May 2022 12:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nqe2k-0007ss-G6 for bug-gnu-emacs@gnu.org; Mon, 16 May 2022 12:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 May 2022 16:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55305 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 55305-submit@debbugs.gnu.org id=B55305.165272025730269 (code B ref 55305); Mon, 16 May 2022 16:58:02 +0000 Original-Received: (at 55305) by debbugs.gnu.org; 16 May 2022 16:57:37 +0000 Original-Received: from localhost ([127.0.0.1]:54924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nqe25-0007ru-QB for submit@debbugs.gnu.org; Mon, 16 May 2022 12:57:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nqe24-0007ri-3C for 55305@debbugs.gnu.org; Mon, 16 May 2022 12:57:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40628) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqe1w-0005PB-QO; Mon, 16 May 2022 12:57:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jqs9E0t1DNeMvhZwWkZEp9c4WCmeebaG03f6tun2KZw=; b=bRKy1GtN8nH+ otH45Eb9LbHTIjQnAxR5KYI3zOyBv79x1PB32cp/6CnS68qxeJNs5tZEzhHlI5sFfAdqFSuZ0qvZJ tY3FOxrftap5BzUSvCwfwCvuAuCkeypgGMenVc7nOy6pMvzDUt4OQcQGH79eLkQH7ANqUKdo3hl6x o/eeIJUV3Xzx1KXCY4vm3OB9Q4+DrrSqxEolIiJeltm+7mfVUtj/BrlTTtf1DNR48+oUzM5QjCzpZ 5zm2ky+fEH6m0R9kGjDy8JSz6DnaT2W2HZVJU6PlVL/lMnnd7ZiZi9hZsY+0GIZlUJEr3HtN4L/An oyxpjiYmqgeZ1xTnZm5DMQ==; Original-Received: from [87.69.77.57] (port=2206 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nqe1w-0000HN-8I; Mon, 16 May 2022 12:57:12 -0400 In-Reply-To: (message from Stefan Monnier on Mon, 16 May 2022 12:40:41 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:232408 Archived-At: > From: Stefan Monnier > Cc: akrl@sdf.org, 55305@debbugs.gnu.org, rswgnu@gmail.com, rsw@gnu.org > Date: Mon, 16 May 2022 12:40:41 -0400 > > Eli Zaretskii [2022-05-16 05:31:01] wrote: > > My worry is about packages that do NOT depend on such macros. Calling > > package-activate-all will activate all the packages on the user's > > system, and there's no way of knowing what those packages do at > > activation time. They can change variables, advise functions, > > redefine commands, etc. > > Yup. I agree it can be worrisome, but: > - Those packages are presumably already activated in the current session > and hence similarly affected the generation of the `.elc` files if the > `.elc` files were generated by `package-install`. Two wrongs don't make one right. Besides, as long as the *.elc files are produced by batch-compilation, this will not happen. And I'm talking only about batch compilation, not about interactive compilation that the user does from a live session. > - Preserving the `load-path` like we already do also exposes similar > problems (some files may shadow the ones we need). The effect of load-path is a much smaller one, and not propagating load-path would cause much graver problems. > > We have no idea what will be the state of the session after > > doing that. > > After the files are compiled, the session is killed (we're talking about > an Emacs sub-process performing native compilation asynchronously), so > I don't think we need to worry too much about that. My worry is about the effects on the produced *.elc/*.eln files, so killing the session doesn't help. > >> I'm not claiming that calling `package-activate-all` is right for > >> reasons of principle. We sadly never clearly defined what it is that > >> a package can count on. > > Then we should do that _before_ we propose solutions that rely on > > what's there, knowing that what's there was never intended to solve > > this particular issue. > > I don't understand what you're saying, here. I'm sating we should define what is it the package can count on before suggesting solutions based on lack of such a definition. > There is a de-facto definition of what a package can count on (which is > that its autoloads file has been loaded), which has been used ever since > the inception of `package.el`. That's when the package is loaded, not when it's compiled. > I don't know enough of what you mean by "this particular issue" to judge > whether this design was made to solve this issue or not, but I do know > that the autoloads file is loaded on purpose before compiling the `.elc` > files so as to make it more convenient to write the code of a package, > just like we happily rely on `loaddefs.el` being loaded when working on > Emacs's bundled code. Loading the loaddefs file by some (as yet nonexistent) mechanism is something I'm prepared to discuss with the purpose of maybe finding some reasonable solution (though it isn't yet clear to me how to do that ion general, for the reasons I explained several messages up-thread). What I'm NOT interested in considering is a call to package-activate-all as part of compiling every Lisp file. > > This cure is worse than the disease. > > My proposed patch is not a cure. The cure would be to compile from the > `.elc` file (since the root of the problem is that we need those > autoloads and the `load-path` to macroexpand the code, and the only > reason why the native-compiler needs to macroexpand the code is because > it (re)starts from the `.el` file instead of using the `.elc` file > where no macro-expansion need to take place). I'm also okay with leaving this issue unsolved until such time as we have native compilation based on .elc files, and revisiting this then.