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: Sat, 14 May 2022 18:05:44 +0300 Message-ID: <83ee0wkvcn.fsf@gnu.org> References: <8335hky5iv.fsf@gnu.org> <83zgjnpaby.fsf@gnu.org> <83tu9vp648.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23017"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55305@debbugs.gnu.org To: rswgnu@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 14 17:07:32 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 1nptMh-0005hL-BS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 May 2022 17:07:31 +0200 Original-Received: from localhost ([::1]:35378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nptMf-0002Mj-UP for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 May 2022 11:07:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43476) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nptME-0002Ma-A2 for bug-gnu-emacs@gnu.org; Sat, 14 May 2022 11:07:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53321) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nptME-0000ZO-16 for bug-gnu-emacs@gnu.org; Sat, 14 May 2022 11:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nptMD-0001aI-IK for bug-gnu-emacs@gnu.org; Sat, 14 May 2022 11:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 May 2022 15:07:01 +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.16525407626005 (code B ref 55305); Sat, 14 May 2022 15:07:01 +0000 Original-Received: (at 55305) by debbugs.gnu.org; 14 May 2022 15:06:02 +0000 Original-Received: from localhost ([127.0.0.1]:47218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nptLG-0001Yh-Fw for submit@debbugs.gnu.org; Sat, 14 May 2022 11:06:02 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nptLE-0001YF-Qz for 55305@debbugs.gnu.org; Sat, 14 May 2022 11:06:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55894) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nptL9-0000OR-I9; Sat, 14 May 2022 11:05:55 -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=VrQ0FGKV70tApVvx5Om653GlhtcgiblxA64XlUHCxE8=; b=V29cNAaFia/j +METilvMM4ErTea1s38W4yfc+gVjs0/6bVnKTUEBUxNJW8gqde1mLCDVU/1z9z5zuIc8fVUy2oUGB rlD9efKvzgHidYvsQ/n+NZZ93pQp/5BvHD86hjj3iD7vxbJpWifbHzvmvv23vQy8U9F2y2oUYktMi Cn6Hw0qjX0oJQe6a+Xh3FtBETUQXb3Hs9ZUWmclVlS8oVghaxH82eMjr9YhAKQF6Pvs7HGA2OSAzJ Elz+j2W8N8gm0GR0E9/7Ir2xxTcRxFOmQruYKY9TMkZr90UJa5xAz6HCaT3rpUaDpn/RpuLGAzjbv Qdk9uVcKUbzJdCfczoTR4g==; Original-Received: from [87.69.77.57] (port=1922 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 1nptL9-0001ZC-1a; Sat, 14 May 2022 11:05:55 -0400 In-Reply-To: (message from Robert Weiner on Sat, 14 May 2022 10:47:40 -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:232241 Archived-At: > From: Robert Weiner > Date: Sat, 14 May 2022 10:47:40 -0400 > Cc: 55305@debbugs.gnu.org > > > loaddefs.el is preloaded into Emacs when it is built, so the analogy > > doesn't work in practice. > > Emacs loads autoloads from a file when it is built (prior to dumping its > image) and I am simply suggesting that both the package manager and the > native compiler do the same for packages. How can a native compiler or a byte compiler know that a given .el file needs some loadefs file to be loaded before it's compiled? Most Lisp files don't have and don't need any loaddefs files to be compiled. For that matter, how can a compiler know that a given .el files _has_ a loaddefs file, and if so, what is its name? Loaddefs files are needed for when a file is loaded, not when it's compiled. For compilation, we have 'require' and 'eval-when-compile', and always had them. Are you saying that 'require' and 'eval-when-compile' should also be replaced by some automation? if so, how can this work even in principle without some meta-data available somewhere for the compiler to find and use? And if we need meta-data, what is wrong with having it in the form of 'require' and 'eval-when-compile' in the file itself? > > I think you should look at bundled packages like Calc. Calc has > > calc-loaddefs.el, but I just now forced Emacs 28.1 to native-compile > > Calc and didn't see any problems. And I see that calc.el does say > > explicitly > > > > ;;;; (Autoloads here) > > (load "calc-loaddefs.el" nil t) > > > > Exactly, calc.el works around this missing feature by explicitly loading > the loaddefs and then having every other calc module require the 'calc' > library. But it isn't just calc.el: every single FOO-loaddefs.el file in the Emacs tree is loaded like that. This is a de-facto standard in how we use the separate loaddefs files of bundled packages. And again, there's nothing new here related to the native compiler: it works the same with the byte compiler, and will output the same warnings if you fail to follow this paradigm. It's nothing new. If you are lobbying for having more automated discovery and loading of loaddefs files, then you are asking for a new feature, not reporting a bug in Emacs 28 that didn't exist in previous versions. And I don't think I agree that this feature is a good idea, for when a file is compiled. But we could discuss this feature request; my point is that there's no bug here, but a normal behavior we have with any compilation of any Lisp file in any Emacs version.