From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 09 00:11:35 2023 Received: (at submit) by debbugs.gnu.org; 9 Apr 2023 04:11:35 +0000 Received: from localhost ([127.0.0.1]:60003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plMOr-0004B7-RM for submit@debbugs.gnu.org; Sun, 09 Apr 2023 00:11:35 -0400 Received: from lists.gnu.org ([209.51.188.17]:46946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plG65-0005YF-6V for submit@debbugs.gnu.org; Sat, 08 Apr 2023 17:27:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1plG65-0005GZ-03 for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2023 17:27:45 -0400 Received: from 046075150076.atmpu0013.highway.a1.net ([46.75.150.76] helo=nixos-laptop.localdomain) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1plG63-0005CY-79 for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2023 17:27:44 -0400 Received: by nixos-laptop.localdomain (Postfix, from userid 1000) id 2CCA6500209; Sat, 8 Apr 2023 23:16:23 +0200 (CEST) From: Leo Georg Gaskin To: bug-gnu-emacs@gnu.org Subject: Always fully rebuild autoloads in package-generate-autoloads Date: Sat, 08 Apr 2023 23:16:23 +0200 Message-ID: <87lej2oz14.fsf@le0.gs> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: none client-ip=46.75.150.76; envelope-from=leo.gaskin@le0.gs; helo=nixos-laptop.localdomain X-Spam_score_int: 15 X-Spam_score: 1.5 X-Spam_bar: + X-Spam_report: (1.5 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.033, RCVD_IN_PBL=3.335, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 09 Apr 2023 00:11:32 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Tags: patch Hello! I've been using the new package-vc.el functionality to great effect, but I have also come across a somewhat annoying bug. If I use any of the provided commands to rebuild my local package while a autoloads file is already present, the newly generated autoloads file is consistently either incomplete or empty. The easiest way I've found to fix this is simply changing the `package-generate-autoloads' function to always rebuild the autoloads file by passing the relevant option to `loaddefs-generate'. I think this change also makes sense on a larger scale, as package generation taking into account older build artifacts seems unintuitive. The attached patch implements this change. I've read that for small changes like this no copyright assignment is needed. If I have misunderstood, please point me to the relevant documents so I can sign them. Please also let me know if I have messed something up or you need any additional information. Best wishes Leo Gaskin In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) Repository revision: 9848ae17161828190cc0ba31e89ae54a2f08a2ef Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 System Description: NixOS 23.05 (Stoat) Configured using: 'configure --prefix=/nix/store/y9bxk3kqk4isr28jcy1bclkdr5a4zd1v-emacs-git-20230407.0 --disable-build-details --with-modules --with-x-toolkit=lucid --with-xft --with-cairo --with-native-compilation' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Always-fully-rebuild-autoloads-in-package-generate-a.patch >From dad173580c048cbe89d5287c4475e965c71a702e Mon Sep 17 00:00:00 2001 From: Leo Gaskin Date: Sat, 8 Apr 2023 23:13:59 +0200 Subject: [PATCH] Always fully rebuild autoloads in package-generate-autoloads --- lisp/emacs-lisp/package.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el index 685f983..09811f1 100644 --- a/lisp/emacs-lisp/package.el +++ b/lisp/emacs-lisp/package.el @@ -1093,7 +1093,8 @@ untar into a directory named DIR; otherwise, signal an error." ;; the load path. We don't hard-code `pkg-dir', to avoid ;; issues if the package directory is moved around. (or (and load-file-name (file-name-directory load-file-name)) - (car load-path))))) + (car load-path)))) + nil t) (let ((buf (find-buffer-visiting output-file))) (when buf (kill-buffer buf))) auto-name)) -- 2.39.2 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 23 09:15:49 2023 Received: (at 62734) by debbugs.gnu.org; 23 Apr 2023 13:15:49 +0000 Received: from localhost ([127.0.0.1]:44853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqZZE-0007lG-OF for submit@debbugs.gnu.org; Sun, 23 Apr 2023 09:15:49 -0400 Received: from mout02.posteo.de ([185.67.36.66]:37291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqZZB-0007l2-Ny for 62734@debbugs.gnu.org; Sun, 23 Apr 2023 09:15:47 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1E40B240129 for <62734@debbugs.gnu.org>; Sun, 23 Apr 2023 15:15:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682255740; bh=L8PXxiXnODEYbEK8rDtDkkeDm99BBLsknBHLW40VSZo=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=AL3kgVN/vbtbbChmoN5+VSCd8iF0vQUUmujt4lXrgGNw0yvvEC3PDYqREYf/FzcLP sfRy4/jhSLo1OHPgC9qZ0Cl4XYeOMESz0ns5kFouG3VtKdOHA5YO3NLHQguP6zwpBn GsUy9cW0ge5HwvXe+esIah4mgN857Hn9ZqFb1Jc6xpZfUfgXkXiESGwdx8w7Tj68Rz 612Kb5yXFQKZcDivyo0C09Lk7CFEjdlyB5K51ig67d3fYErHXeEYKUFiowapHGfD3z iWZcuHdK6tIrE6+HAhIXIHMv+EeAjN4hSqBuDgkM/7eG+OrYTSfCKu0QYfSHL4Xn/0 VT2icvP9fvQ9Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q47zt4X8nz6tvx; Sun, 23 Apr 2023 15:15:38 +0200 (CEST) From: Philip Kaludercic To: Leo Georg Gaskin Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <87lej2oz14.fsf@le0.gs> (Leo Georg Gaskin's message of "Sat, 08 Apr 2023 23:16:23 +0200") References: <87lej2oz14.fsf@le0.gs> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Sun, 23 Apr 2023 13:16:10 +0000 Message-ID: <87pm7u7n8l.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Leo Georg Gaskin writes: > Tags: patch > > Hello! > > I've been using the new package-vc.el functionality to great effect, > but I have also come across a somewhat annoying bug. If I use any of > the provided commands to rebuild my local package while a autoloads > file is already present, the newly generated autoloads file is > consistently either incomplete or empty. Can you reproduce this using emacs -Q? > The easiest way I've found to fix this is simply changing the > `package-generate-autoloads' function to always rebuild the autoloads > file by passing the relevant option to `loaddefs-generate'. I think > this change also makes sense on a larger scale, as package generation > taking into account older build artifacts seems unintuitive. I guess this could work, but it might also be an inconvenience for people with a lot of packages? It seems to me that trying to better understand the issue before proceeding to apply this quick fix would be a better idea. What do you think? > The attached patch implements this change. > > I've read that for small changes like this no copyright assignment > is needed. If I have misunderstood, please point me to the relevant > documents so I can sign them. Please also let me know if I have > messed something up or you need any additional information. That should be the case. > > Best wishes > > Leo Gaskin > > > In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo > version 1.16.0, Xaw3d scroll bars) > Repository revision: 9848ae17161828190cc0ba31e89ae54a2f08a2ef > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 > System Description: NixOS 23.05 (Stoat) > > Configured using: > 'configure > --prefix=/nix/store/y9bxk3kqk4isr28jcy1bclkdr5a4zd1v-emacs-git-20230407.0 > --disable-build-details --with-modules --with-x-toolkit=lucid > --with-xft --with-cairo --with-native-compilation' > >>>From dad173580c048cbe89d5287c4475e965c71a702e Mon Sep 17 00:00:00 2001 > From: Leo Gaskin > Date: Sat, 8 Apr 2023 23:13:59 +0200 > Subject: [PATCH] Always fully rebuild autoloads in package-generate-autoloads > > --- > lisp/emacs-lisp/package.el | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > index 685f983..09811f1 100644 > --- a/lisp/emacs-lisp/package.el > +++ b/lisp/emacs-lisp/package.el > @@ -1093,7 +1093,8 @@ untar into a directory named DIR; otherwise, signal an error." > ;; the load path. We don't hard-code `pkg-dir', to avoid > ;; issues if the package directory is moved around. > (or (and load-file-name (file-name-directory load-file-name)) > - (car load-path))))) > + (car load-path)))) > + nil t) > (let ((buf (find-buffer-visiting output-file))) > (when buf (kill-buffer buf))) > auto-name)) From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 23 10:36:42 2023 Received: (at 62734) by debbugs.gnu.org; 23 Apr 2023 14:36:42 +0000 Received: from localhost ([127.0.0.1]:46568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqapW-00025A-AI for submit@debbugs.gnu.org; Sun, 23 Apr 2023 10:36:42 -0400 Received: from mail-yb1-f181.google.com ([209.85.219.181]:48432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pqapR-00024u-IG for 62734@debbugs.gnu.org; Sun, 23 Apr 2023 10:36:40 -0400 Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-b8f5121503eso5035859276.1 for <62734@debbugs.gnu.org>; Sun, 23 Apr 2023 07:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=le0-gs.20221208.gappssmtp.com; s=20221208; t=1682260591; x=1684852591; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wc/VF2RdOMVyN71PgZmyknfEUWha3xdp55DJCZPsZ7o=; b=oNi2R3OnclqycifEov+RpFp4ikuQajiZJ6KtwuvnicIo35tnUZzUmLVyMuBopuFqyH 9s/P7OdCLI8i1+TZKGA4XlxLMH7P0vOPBf4Gmkefue8lJzQlA/yEnwqCVfBhxgokjytZ kbeHx7TydWAjh545oT6BZeyY1Pu3yAJk5J2xuIMk4i+qEH9JoYSvJeUIUmvyFohyq+HB EPh6yTRYB+FdGJY2PrHs0IIr7dTBaHviWzPNhCxtv3GvnF4kfupeygvMpta53osKznfD ODx070H9QkXVOBEKLmlGIapF9X/PSQXQuzSnsn2hS8xN98ugnZo8mMVmgMSounLWD81b wx6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682260591; x=1684852591; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wc/VF2RdOMVyN71PgZmyknfEUWha3xdp55DJCZPsZ7o=; b=kQaooyY2ljRrwSZ0+N5jEkn+v5zV/NYj57/GjkLvTOX4GGYxR4LBdDM9VlpnGX35bs ntqzaaz39uvcuwdSnUMVFXuVumoPcEb6xmG+uwz7tTspUBqxrnSkw0YXtauaOvAFaq1b tXbqJEAOsLHXqdEstEOhgS9QGWhy4mbs0N8/AgtSffPxkvlc9DVJk16xEPsqnUi3vJVW e8ycEEIVFvigsa1Rujba3uCAypL2zn0wfLmmnBxRtP4XseDMROLLQwfKNxZWKEf1XqKW M5wn/k8/nEZTrIIUBmWMQZHdq0ZU4KdeuIYEfz82vv2rVzVbarnjzsS/MgGloEotsU2J DkWA== X-Gm-Message-State: AAQBX9d4c3WPHhcRzroBHPlbVofufEYn4Ei0K+4CXKtzf9oqB6kdXCLa YRGVoN9+yDQkp7D5dePVEM1KM7m/xs8xwPhQPSAmtQ== X-Google-Smtp-Source: AKy350Z6qBlgr+dcqhovbOcLktpNSCUJh+ozta9Wm9OVGP6H8DGOaf8hUCTO56EQBmnHnFzDlteJeyvrYm8WBM1oGxU= X-Received: by 2002:a25:60c1:0:b0:b8f:6bcc:3d60 with SMTP id u184-20020a2560c1000000b00b8f6bcc3d60mr6793810ybb.64.1682260591710; Sun, 23 Apr 2023 07:36:31 -0700 (PDT) MIME-Version: 1.0 References: <87lej2oz14.fsf@le0.gs> <87pm7u7n8l.fsf@posteo.net> In-Reply-To: <87pm7u7n8l.fsf@posteo.net> From: Leo Gaskin Date: Sun, 23 Apr 2023 16:36:20 +0200 Message-ID: Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads To: Philip Kaludercic Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Can you reproduce this using emacs -Q? Yes I can. When I run the command `M-x package-vc-install helm RET', then `M-x package-vc-rebuild helm RET' immediately after, in an Emacs instance launched with the -Q option, the helm-autoloads.el file does not contain the expected autoloads for the Helm package. > I guess this could work, but it might also be an inconvenience for > people with a lot of packages? I think `package-generate-autoloads' already rarely or never reuses previously generated autoloads files. It seems to me that `package-vc-rebuild' is currently the only function that calls `package-generate-autoloads' on a package with autoloads files already present. Other functions such as `package-update' first delete the old package, meaning an old autoloads file is never present. Also, for me at least, the amount of time it takes to generate these autoload files is not really noticeable, at least compared the time it takes to byte-compile the package. > It seems to me that trying to better > understand the issue before proceeding to apply this quick fix would be > a better idea. What do you think? Sure, it would be a good idea to understand the underlying problem. Unfortunately I do not understand the loaddefs generation code well enough to offer a better fix right now. Investigating the issue further would take more time, which I likely won't be able to spend on this this month. On Sun, Apr 23, 2023 at 3:15=E2=80=AFPM Philip Kaludercic wrote: > > Leo Georg Gaskin writes: > > > Tags: patch > > > > Hello! > > > > I've been using the new package-vc.el functionality to great effect, > > but I have also come across a somewhat annoying bug. If I use any of > > the provided commands to rebuild my local package while a autoloads > > file is already present, the newly generated autoloads file is > > consistently either incomplete or empty. > > Can you reproduce this using emacs -Q? > > > The easiest way I've found to fix this is simply changing the > > `package-generate-autoloads' function to always rebuild the autoloads > > file by passing the relevant option to `loaddefs-generate'. I think > > this change also makes sense on a larger scale, as package generation > > taking into account older build artifacts seems unintuitive. > > I guess this could work, but it might also be an inconvenience for > people with a lot of packages? It seems to me that trying to better > understand the issue before proceeding to apply this quick fix would be > a better idea. What do you think? > > > The attached patch implements this change. > > > > I've read that for small changes like this no copyright assignment > > is needed. If I have misunderstood, please point me to the relevant > > documents so I can sign them. Please also let me know if I have > > messed something up or you need any additional information. > > That should be the case. > > > > > Best wishes > > > > Leo Gaskin > > > > > > In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo > > version 1.16.0, Xaw3d scroll bars) > > Repository revision: 9848ae17161828190cc0ba31e89ae54a2f08a2ef > > Repository branch: master > > Windowing system distributor 'The X.Org Foundation', version 11.0.12101= 008 > > System Description: NixOS 23.05 (Stoat) > > > > Configured using: > > 'configure > > --prefix=3D/nix/store/y9bxk3kqk4isr28jcy1bclkdr5a4zd1v-emacs-git-20230= 407.0 > > --disable-build-details --with-modules --with-x-toolkit=3Dlucid > > --with-xft --with-cairo --with-native-compilation' > > > >>From dad173580c048cbe89d5287c4475e965c71a702e Mon Sep 17 00:00:00 2001 > > From: Leo Gaskin > > Date: Sat, 8 Apr 2023 23:13:59 +0200 > > Subject: [PATCH] Always fully rebuild autoloads in package-generate-aut= oloads > > > > --- > > lisp/emacs-lisp/package.el | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el > > index 685f983..09811f1 100644 > > --- a/lisp/emacs-lisp/package.el > > +++ b/lisp/emacs-lisp/package.el > > @@ -1093,7 +1093,8 @@ untar into a directory named DIR; otherwise, sign= al an error." > > ;; the load path. We don't hard-code `pkg-dir', to avoid > > ;; issues if the package directory is moved around. > > (or (and load-file-name (file-name-directory load-file-name)) > > - (car load-path))))) > > + (car load-path)))) > > + nil t) > > (let ((buf (find-buffer-visiting output-file))) > > (when buf (kill-buffer buf))) > > auto-name)) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 25 08:35:11 2023 Received: (at 62734) by debbugs.gnu.org; 25 Apr 2023 12:35:11 +0000 Received: from localhost ([127.0.0.1]:51622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prHt1-0005b9-3i for submit@debbugs.gnu.org; Tue, 25 Apr 2023 08:35:11 -0400 Received: from mout02.posteo.de ([185.67.36.66]:34847) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1prHsv-0005aN-T8 for 62734@debbugs.gnu.org; Tue, 25 Apr 2023 08:35:08 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id BE846240507 for <62734@debbugs.gnu.org>; Tue, 25 Apr 2023 14:34:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682426099; bh=27unQAk3P5i7G5YL6RKoMdfBt75t+NzCleGdCbaZGrw=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=QwimbeBCk9eKonigzqFJ7hjh1dsIcxcAbMcLFt+1LKSIHaBV3idGrT2nfnAaYkkCD 9KZ8G4bZK7QGjObh2KRfUx3qkcm2yIrS18hHT1cASKhxe9wmOSvk5AUJ6YaBRNXIzb UI8KXeNcPspGAtZSxJfXvoaBbpsns6UVNY9fM6C6xZ4rwaeKpuV16w3OVYG/jrlxxe Bv7p1bTOFePXU5zniPKMX9EyHUOGoXU6catamWJ9O10gDYD1vAeAFLNe4Pnw0LEwmt uv8mSOZ6oxOfk8Y1OhREDJKvijtYP/gJ2N8Eci9moNaFQplhKWdYiPDQ4JxE9UTVrZ mNKu49Ksgepsw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q5M016Fdgz6tw1; Tue, 25 Apr 2023 14:34:57 +0200 (CEST) From: Philip Kaludercic To: Leo Gaskin Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: (Leo Gaskin's message of "Sun, 23 Apr 2023 16:36:20 +0200") References: <87lej2oz14.fsf@le0.gs> <87pm7u7n8l.fsf@posteo.net> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Tue, 25 Apr 2023 12:35:30 +0000 Message-ID: <878regb0ml.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Leo Gaskin writes: >> Can you reproduce this using emacs -Q? > > Yes I can. When I run the command `M-x package-vc-install helm RET', > then `M-x package-vc-rebuild helm RET' immediately after, in an Emacs > instance launched with the -Q option, the helm-autoloads.el file does > not contain the expected autoloads for the Helm package. Ok, thanks. >> I guess this could work, but it might also be an inconvenience for >> people with a lot of packages? > > I think `package-generate-autoloads' already rarely or never reuses > previously generated autoloads files. Why shouldn't it, shouldn't the list of autoloads of a package stay relatively constant over package releases? > It seems to me that `package-vc-rebuild' is currently the only function > that calls `package-generate-autoloads' on a package with autoloads > files already present.=20=20 True, the only other case is `package-unpack' (via the function `package--make-autoloads-and-stuff'), which are respectively only invoked by `package-install-from-archive' and `package-install-from-buffer', both of which do not re-use anything. > Other functions such as `package-update' first > delete the old package, meaning an old autoloads file is never present. Right. > Also, for me at least, the amount of time it takes to generate these > autoload files is not really noticeable, at least compared the time it > takes to byte-compile the package. I do not know if this is always the case, but I wouldn't be surprised if that was so. >> It seems to me that trying to better >> understand the issue before proceeding to apply this quick fix would be >> a better idea. What do you think? > > Sure, it would be a good idea to understand the underlying problem. > Unfortunately I do not understand the loaddefs generation code well > enough to offer a better fix right now. Investigating the issue further > would take more time, which I likely won't be able to spend on this > this month. This might also very well be an issue with package-vc. Either way, I will take a look at it, perhaps there might be a better understood solution (even though your fix looks like it should be safe). If I don't find anything, we can always "fall back" on to the patch you provided. > On Sun, Apr 23, 2023 at 3:15=E2=80=AFPM Philip Kaludercic wrote: >> >> Leo Georg Gaskin writes: >> >> > Tags: patch >> > >> > Hello! >> > >> > I've been using the new package-vc.el functionality to great effect, >> > but I have also come across a somewhat annoying bug. If I use any of >> > the provided commands to rebuild my local package while a autoloads >> > file is already present, the newly generated autoloads file is >> > consistently either incomplete or empty. >> >> Can you reproduce this using emacs -Q? >> >> > The easiest way I've found to fix this is simply changing the >> > `package-generate-autoloads' function to always rebuild the autoloads >> > file by passing the relevant option to `loaddefs-generate'. I think >> > this change also makes sense on a larger scale, as package generation >> > taking into account older build artifacts seems unintuitive. >> >> I guess this could work, but it might also be an inconvenience for >> people with a lot of packages? It seems to me that trying to better >> understand the issue before proceeding to apply this quick fix would be >> a better idea. What do you think? >> >> > The attached patch implements this change. >> > >> > I've read that for small changes like this no copyright assignment >> > is needed. If I have misunderstood, please point me to the relevant >> > documents so I can sign them. Please also let me know if I have >> > messed something up or you need any additional information. >> >> That should be the case. >> >> > >> > Best wishes >> > >> > Leo Gaskin >> > >> > >> > In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo >> > version 1.16.0, Xaw3d scroll bars) >> > Repository revision: 9848ae17161828190cc0ba31e89ae54a2f08a2ef >> > Repository branch: master >> > Windowing system distributor 'The X.Org Foundation', version 11.0.1210= 1008 >> > System Description: NixOS 23.05 (Stoat) >> > >> > Configured using: >> > 'configure >> > --prefix=3D/nix/store/y9bxk3kqk4isr28jcy1bclkdr5a4zd1v-emacs-git-2023= 0407.0 >> > --disable-build-details --with-modules --with-x-toolkit=3Dlucid >> > --with-xft --with-cairo --with-native-compilation' >> > >> >>From dad173580c048cbe89d5287c4475e965c71a702e Mon Sep 17 00:00:00 2001 >> > From: Leo Gaskin >> > Date: Sat, 8 Apr 2023 23:13:59 +0200 >> > Subject: [PATCH] Always fully rebuild autoloads in package-generate-au= toloads >> > >> > --- >> > lisp/emacs-lisp/package.el | 3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el >> > index 685f983..09811f1 100644 >> > --- a/lisp/emacs-lisp/package.el >> > +++ b/lisp/emacs-lisp/package.el >> > @@ -1093,7 +1093,8 @@ untar into a directory named DIR; otherwise, sig= nal an error." >> > ;; the load path. We don't hard-code `pkg-dir', to avoid >> > ;; issues if the package directory is moved around. >> > (or (and load-file-name (file-name-directory load-file-name)) >> > - (car load-path))))) >> > + (car load-path)))) >> > + nil t) >> > (let ((buf (find-buffer-visiting output-file))) >> > (when buf (kill-buffer buf))) >> > auto-name)) From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 28 10:59:41 2023 Received: (at 62734) by debbugs.gnu.org; 28 Apr 2023 14:59:41 +0000 Received: from localhost ([127.0.0.1]:34218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psPZV-0006K0-C6 for submit@debbugs.gnu.org; Fri, 28 Apr 2023 10:59:41 -0400 Received: from mout01.posteo.de ([185.67.36.65]:39279) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psPZQ-0006Jf-Qs for 62734@debbugs.gnu.org; Fri, 28 Apr 2023 10:59:39 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 09042240384 for <62734@debbugs.gnu.org>; Fri, 28 Apr 2023 16:59:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682693971; bh=rHozKhkB2yPZ0toRAQwR2/HLEM4yVvVqsh4ZD3w3QjQ=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=emlLG9Sx/+nd9bgCTRBbCjv9WgmFfaqcuM9oxjuTsyVyO+5ZOGU9G22GqEpPPnsTZ NI2+x+8VgQLfNTKm/5lqq+d+BfW7ZlpHGRKznHfYIkSRSI97Rig/rBW3lft7RXQemD kbVesS5TOud83MNYo+8JCKNU3O9fAUy18tfpik0W7agMToJc+1UguFyLo5dwswg7Rt yoYWJ3VyJQqLxTugLNtsM/G6BsqvwFwZz/MoTzdeX31hwsjGFqkN8QhdoJTfARIDGd VkJxhGHyIY9nhioxXZPhuZyoPcTV/DdP+PE92RHD4nibayKOpEgC9ECSNrjr7Vjjaa +qI1RiVEfDkTQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7G3N75Q7z6tvc; Fri, 28 Apr 2023 16:59:28 +0200 (CEST) From: Philip Kaludercic To: Leo Georg Gaskin Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <87lej2oz14.fsf@le0.gs> (Leo Georg Gaskin's message of "Sat, 08 Apr 2023 23:16:23 +0200") References: <87lej2oz14.fsf@le0.gs> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Fri, 28 Apr 2023 15:00:02 +0000 Message-ID: <874jp0aw7h.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, 'Eli Zaretskii' X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Leo Georg Gaskin writes: > Tags: patch > > Hello! > > I've been using the new package-vc.el functionality to great effect, > but I have also come across a somewhat annoying bug. If I use any of > the provided commands to rebuild my local package while a autoloads > file is already present, the newly generated autoloads file is > consistently either incomplete or empty. > > The easiest way I've found to fix this is simply changing the > `package-generate-autoloads' function to always rebuild the autoloads > file by passing the relevant option to `loaddefs-generate'. I think > this change also makes sense on a larger scale, as package generation > taking into account older build artifacts seems unintuitive. > > The attached patch implements this change. > > I've read that for small changes like this no copyright assignment > is needed. If I have misunderstood, please point me to the relevant > documents so I can sign them. Please also let me know if I have > messed something up or you need any additional information. It seems to me that your fix is the easiest way to tackle the issue, without having to do a deep-dive into loaddefs. Eli, can this be applied to emacs-29? An alternative fix would be to restrict the changes to package-vc, but that seems like an unnecessary duplication, since the change doesn't affect package. > Best wishes > > Leo Gaskin > > > In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo > version 1.16.0, Xaw3d scroll bars) > Repository revision: 9848ae17161828190cc0ba31e89ae54a2f08a2ef > Repository branch: master > Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 > System Description: NixOS 23.05 (Stoat) > > Configured using: > 'configure > --prefix=/nix/store/y9bxk3kqk4isr28jcy1bclkdr5a4zd1v-emacs-git-20230407.0 > --disable-build-details --with-modules --with-x-toolkit=lucid > --with-xft --with-cairo --with-native-compilation' From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 28 11:48:15 2023 Received: (at 62734) by debbugs.gnu.org; 28 Apr 2023 15:48:15 +0000 Received: from localhost ([127.0.0.1]:34273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psQKU-0007zw-Jw for submit@debbugs.gnu.org; Fri, 28 Apr 2023 11:48:15 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psQKR-0007yw-1L for 62734@debbugs.gnu.org; Fri, 28 Apr 2023 11:48:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psQKK-0002su-Pk; Fri, 28 Apr 2023 11:48:04 -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=QYwVjnDoG/mO/7tI2QgHBqPPOlEqmwR/luNXqltxLQI=; b=W8eVF0TJ4+SB daNCVbguOzLNZg6DbISLizgadiuidp6MLAY3qdikkwcyT4PYCM4ym8zV6QcLTZJF7WFIulEcluYzI a5zpQLyIMQBQbLhjUyBWp4fzkB8zL6mV+LpJ51BgllbT0KS+qU9NMqOx/iuxKW8rQrAbH1ZUK0Hln wK4Zzz07ixW/5LuD2ESPJ30cBEW+x8UL+Qk05zoW+L2ih0y2ZhZwxRzZgOTMwIXOWlQFnn1P0t3TV NCTDYccqQ4tXUpicuiXsipXYyP2fhCDcRdxXXfvi0o4oF3hcYbjGktYg1AmPw/hu+b7jAlcgseIE0 OX7tDT+EEWQFoRCE0CVumg==; Received: from [87.69.77.57] (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 1psQKK-0002fL-3T; Fri, 28 Apr 2023 11:48:04 -0400 Date: Fri, 28 Apr 2023 18:48:38 +0300 Message-Id: <83pm7oqa7d.fsf@gnu.org> From: Eli Zaretskii To: Philip Kaludercic In-Reply-To: <874jp0aw7h.fsf@posteo.net> (message from Philip Kaludercic on Fri, 28 Apr 2023 15:00:02 +0000) Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Philip Kaludercic > Cc: 62734@debbugs.gnu.org, "'Eli Zaretskii'" > Date: Fri, 28 Apr 2023 15:00:02 +0000 > > Leo Georg Gaskin writes: > > > Tags: patch > > > > Hello! > > > > I've been using the new package-vc.el functionality to great effect, > > but I have also come across a somewhat annoying bug. If I use any of > > the provided commands to rebuild my local package while a autoloads > > file is already present, the newly generated autoloads file is > > consistently either incomplete or empty. > > > > The easiest way I've found to fix this is simply changing the > > `package-generate-autoloads' function to always rebuild the autoloads > > file by passing the relevant option to `loaddefs-generate'. I think > > this change also makes sense on a larger scale, as package generation > > taking into account older build artifacts seems unintuitive. > > > > The attached patch implements this change. > > > > I've read that for small changes like this no copyright assignment > > is needed. If I have misunderstood, please point me to the relevant > > documents so I can sign them. Please also let me know if I have > > messed something up or you need any additional information. > > It seems to me that your fix is the easiest way to tackle the issue, > without having to do a deep-dive into loaddefs. Eli, can this be > applied to emacs-29? An alternative fix would be to restrict the > changes to package-vc, but that seems like an unnecessary duplication, > since the change doesn't affect package. I don't understand the original problem (what does package-vc.el have to do with rebuilding local packages? and why is a newly generated loaddefs file incomplete or empty?), and I certainly don't think I understand the effects of this change on the other usage scenarios. Why would we want to unconditionally rebuild all the loaddefs files every time package-generate-autoloads is invoked? OTOH, that function is not really documented, so maybe I don't understand what is it supposed to do and in which conditions. IOW, I think we need more details about the problem and the proposed solution. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 28 13:59:52 2023 Received: (at 62734) by debbugs.gnu.org; 28 Apr 2023 17:59:52 +0000 Received: from localhost ([127.0.0.1]:34422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSNs-0003f7-45 for submit@debbugs.gnu.org; Fri, 28 Apr 2023 13:59:52 -0400 Received: from mout01.posteo.de ([185.67.36.65]:37899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSNo-0003er-Vw for 62734@debbugs.gnu.org; Fri, 28 Apr 2023 13:59:50 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E417A240113 for <62734@debbugs.gnu.org>; Fri, 28 Apr 2023 19:59:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682704782; bh=+Q4FaTQk7nmoc4/+oK+Hm8Y+QlMnLB7fz0vH7gJwt4s=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=FT2xqPuk2gItSYfREnVeUScx3GS3rkya08iG/RTUVCgqKTYDqCcwsVvLYXhIBCGua N9o4T1IVBJbL4PN/Z94jPBQKhDynAa4qxx+gzbD8NEmbcGI2uYE9GnPXffYlpntgCJ 8cSahUEsTNBPOED4KNqnW+tc0fn8lgg6yg41ZkN3F0zdi6axYb2MX69qWV0qTd/BPu xVlVgAKo++IJrycY6epLAOBRV1Pi6tULm1SjH07mbTN5CXaNZg+jWgXovBPAyT2a9E k4D5O7GRZgDnHXNtzSUayjUeUlZtxJGdJIHiEm39xm+jN5aOswDVmvuvvPKGmFoSOB Zn5tZzKKqXAoA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7L3L37dFz6tvr; Fri, 28 Apr 2023 19:59:42 +0200 (CEST) From: Philip Kaludercic To: Eli Zaretskii Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <83pm7oqa7d.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 28 Apr 2023 18:48:38 +0300") References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Fri, 28 Apr 2023 18:00:14 +0000 Message-ID: <87o7n7ga4x.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: 62734@debbugs.gnu.org, "'Eli Zaretskii'" >> Date: Fri, 28 Apr 2023 15:00:02 +0000 >> >> Leo Georg Gaskin writes: >> >> > Tags: patch >> > >> > Hello! >> > >> > I've been using the new package-vc.el functionality to great effect, >> > but I have also come across a somewhat annoying bug. If I use any of >> > the provided commands to rebuild my local package while a autoloads >> > file is already present, the newly generated autoloads file is >> > consistently either incomplete or empty. >> > >> > The easiest way I've found to fix this is simply changing the >> > `package-generate-autoloads' function to always rebuild the autoloads >> > file by passing the relevant option to `loaddefs-generate'. I think >> > this change also makes sense on a larger scale, as package generation >> > taking into account older build artifacts seems unintuitive. >> > >> > The attached patch implements this change. >> > >> > I've read that for small changes like this no copyright assignment >> > is needed. If I have misunderstood, please point me to the relevant >> > documents so I can sign them. Please also let me know if I have >> > messed something up or you need any additional information. >> >> It seems to me that your fix is the easiest way to tackle the issue, >> without having to do a deep-dive into loaddefs. Eli, can this be >> applied to emacs-29? An alternative fix would be to restrict the >> changes to package-vc, but that seems like an unnecessary duplication, >> since the change doesn't affect package. > > I don't understand the original problem (what does package-vc.el have > to do with rebuilding local packages? When package updates a package, it deletes the old code and downloads the new stuff. package-vc keeps the same code, but pulls the new revisions, so it is necessary to re-generate the loaddef files for the same files. > and why is a newly generated > loaddefs file incomplete or empty?), and I certainly don't think I > understand the effects of this change on the other usage scenarios. >From what I get, this is an issue in `loaddefs-generate'. If we do not force updating the file, and --8<---------------cut here---------------start------------->8--- (time-less-p output-time (file-attribute-modification-time (file-attributes file))) --8<---------------cut here---------------end--------------->8--- does not hold, then we do not collect any new definitions stored in `defs'. But since we do pass `extra-data' via the function `package-generate-autoloads', that we evaluate this expression --8<---------------cut here---------------start------------->8--- (with-temp-buffer (insert (loaddefs-generate--rubric output-file nil t)) (search-forward "\f") (insert extra-data) (ensure-empty-lines 1) (write-region (point-min) (point-max) output-file nil 'silent)) --8<---------------cut here---------------end--------------->8--- that overwrites the entire file. Thinking about this again, it might be possible to just fix this in `loaddefs-generate', but trying to re-use an existing file --8<---------------cut here---------------start------------->8--- (if (file-exists-p output-file) (insert-file-contents output-file) (insert (loaddefs-generate--rubric output-file nil t))) --8<---------------cut here---------------end--------------->8--- but that assumes that `extra-data' (a string) would never contain a form feed character... Another idea is just to get rid of this faulty optimisation. From my tests this would also resolve the bug. > Why would we want to unconditionally rebuild all the loaddefs files > every time package-generate-autoloads is invoked? OTOH, that function > is not really documented, so maybe I don't understand what is it > supposed to do and in which conditions. The matter was that for regular packages, it was already rebuilt every time `loaddefs-generate' was invoked, since there were never any old loaddefs to update. > IOW, I think we need more details about the problem and the proposed > solution. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 28 14:10:52 2023 Received: (at 62734) by debbugs.gnu.org; 28 Apr 2023 18:10:52 +0000 Received: from localhost ([127.0.0.1]:34437 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSYV-0003wq-V3 for submit@debbugs.gnu.org; Fri, 28 Apr 2023 14:10:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSYR-0003wa-1S for 62734@debbugs.gnu.org; Fri, 28 Apr 2023 14:10:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psSYK-00085B-TD; Fri, 28 Apr 2023 14:10:40 -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=QlYKddIKLdFqV5R86nBmuWFMk8ZQIlXQBPef5MtIw5c=; b=atO9G/AsiR/s usS03jzpBZPWYL8aXnIs/70N4M5XLfh+CEDpxz6bzUEYaWPgsKg4y/PnRNNJyH0N4Fc58fL0cQc6e NG/zXFzK1XCXNMBzQyQITjii8OxLWsp7OWoC+J32UB965p6qRD/qiS9FjBeuEKeavC7GORn2FEaGR CNkH3V4aBQN4Zi8aqeF8Oo8W44nQo+QP2Dt0xgRkgShJ0nErX72AFcxrilRMncwB96MZq7EL970Ei Fj/raTbSIcUQqCvbQzUzNibiszKDcu+9FGxiQS/rjRnX0KyznThSEreVfR7PWkBsEgPVlfkh9ZUzo E8nD9JELYrDsfKSS3Bh+9w==; Received: from [87.69.77.57] (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 1psSYK-0002Hk-DQ; Fri, 28 Apr 2023 14:10:40 -0400 Date: Fri, 28 Apr 2023 21:11:15 +0300 Message-Id: <83o7n7ri64.fsf@gnu.org> From: Eli Zaretskii To: Philip Kaludercic In-Reply-To: <87o7n7ga4x.fsf@posteo.net> (message from Philip Kaludercic on Fri, 28 Apr 2023 18:00:14 +0000) Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Philip Kaludercic > Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org > Date: Fri, 28 Apr 2023 18:00:14 +0000 > > > I don't understand the original problem (what does package-vc.el have > > to do with rebuilding local packages? > > When package updates a package, it deletes the old code and downloads > the new stuff. package-vc keeps the same code, but pulls the new > revisions, so it is necessary to re-generate the loaddef files for the > same files. What is meant by "building the package"? Is it just compiling the Lisp files? > > and why is a newly generated > > loaddefs file incomplete or empty?), and I certainly don't think I > > understand the effects of this change on the other usage scenarios. > > >From what I get, this is an issue in `loaddefs-generate'. If we do not > force updating the file, and > > --8<---------------cut here---------------start------------->8--- > (time-less-p output-time > (file-attribute-modification-time > (file-attributes file))) > --8<---------------cut here---------------end--------------->8--- > > does not hold Why would it not hold? Updating from VCS should update the timestamp of the updated files. > Another idea is just to get rid of this faulty optimisation. From my > tests this would also resolve the bug. I don't yet understand what optimization is that, but getting rid of it should not alter what the code does for the loaddefs files inside the Emacs tree, because there it does work, and I don't want to touch that. > > Why would we want to unconditionally rebuild all the loaddefs files > > every time package-generate-autoloads is invoked? OTOH, that function > > is not really documented, so maybe I don't understand what is it > > supposed to do and in which conditions. > > The matter was that for regular packages, it was already rebuilt every > time `loaddefs-generate' was invoked, since there were never any old > loaddefs to update. This is only true as long as updating a package removes the previous version entirely, including the generated files. This is not something I'd like us to assume in every corner of package.el, since some day it can become false. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 28 14:22:26 2023 Received: (at 62734) by debbugs.gnu.org; 28 Apr 2023 18:22:26 +0000 Received: from localhost ([127.0.0.1]:34446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSje-0004EG-OG for submit@debbugs.gnu.org; Fri, 28 Apr 2023 14:22:26 -0400 Received: from mout02.posteo.de ([185.67.36.66]:36473) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psSjZ-0004Dy-OS for 62734@debbugs.gnu.org; Fri, 28 Apr 2023 14:22:21 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A495524033A for <62734@debbugs.gnu.org>; Fri, 28 Apr 2023 20:22:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682706131; bh=PMmJa0tMblbFdzrcGYBm6HqvapFSSmCll2+FTNbPbgg=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=fhHRlG+0w1NLGKa6bQ1NFw8H1568IGI3rW7MF2TCB47TDd/vkZYuTjakxfoYqWywF jmSTFOoDplD7IQajEplg6imDW+yTGCI/FQDfR7U8qCiUUDW9XJYzlAiZPxdiTdI0JW mpCsG4LB/HxQhCNgjhDV8DCs3a2S+Khe1tDs9Ftm6NXPzJ9vHT+jDc94gjjQW58QC4 AjvzVdyNq10QbbNbsteQiTXBGYec0pRtcLFww59GrYy7X35jQrl+3RCte8+0Mw9DUi MXUie5/VofZbml46VzcfdAZT+nJOi+Suwh3CbpIhWZ53KTijBKQsARKUfQqsJwby25 MBtfARFUBGulA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7LYH1b1Dz6txV; Fri, 28 Apr 2023 20:22:11 +0200 (CEST) From: Philip Kaludercic To: Eli Zaretskii Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <83o7n7ri64.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 28 Apr 2023 21:11:15 +0300") References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Fri, 28 Apr 2023 18:22:43 +0000 Message-ID: <87fs8jg93g.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Fri, 28 Apr 2023 18:00:14 +0000 >> >> > I don't understand the original problem (what does package-vc.el have >> > to do with rebuilding local packages? >> >> When package updates a package, it deletes the old code and downloads >> the new stuff. package-vc keeps the same code, but pulls the new >> revisions, so it is necessary to re-generate the loaddef files for the >> same files. > > What is meant by "building the package"? Is it just compiling the > Lisp files? >From `package-vc-rebuild': Rebuilding an installation means scraping for new autoload cookies, re-compiling Emacs Lisp files, building and installing any documentation, downloading any missing dependencies. >> > and why is a newly generated >> > loaddefs file incomplete or empty?), and I certainly don't think I >> > understand the effects of this change on the other usage scenarios. >> >> >From what I get, this is an issue in `loaddefs-generate'. If we do not >> force updating the file, and >> >> --8<---------------cut here---------------start------------->8--- >> (time-less-p output-time >> (file-attribute-modification-time >> (file-attributes file))) >> --8<---------------cut here---------------end--------------->8--- >> >> does not hold > > Why would it not hold? Updating from VCS should update the timestamp > of the updated files. I don't think this necessarily holds if there were no changes affecting a file. >> Another idea is just to get rid of this faulty optimisation. From my >> tests this would also resolve the bug. > > I don't yet understand what optimization is that, but getting rid of > it should not alter what the code does for the loaddefs files inside > the Emacs tree, because there it does work, and I don't want to touch > that. Are you sure it does work? I am currently having difficulties understanding how the `with-temp-buffer' code snippet I quoted above /can/ do the right thing. I am under the impression that wherever `loaddefs-generate' is invoked, it avoids this execution path, either by passing no EXTRA-DATA or by making sure that at least some autoload is collected. >> > Why would we want to unconditionally rebuild all the loaddefs files >> > every time package-generate-autoloads is invoked? OTOH, that function >> > is not really documented, so maybe I don't understand what is it >> > supposed to do and in which conditions. >> >> The matter was that for regular packages, it was already rebuilt every >> time `loaddefs-generate' was invoked, since there were never any old >> loaddefs to update. > > This is only true as long as updating a package removes the previous > version entirely, including the generated files. This is not > something I'd like us to assume in every corner of package.el, since > some day it can become false. Ok, fair point considering that package-vc currently does this. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 29 01:42:39 2023 Received: (at 62734) by debbugs.gnu.org; 29 Apr 2023 05:42:39 +0000 Received: from localhost ([127.0.0.1]:34916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psdLy-0007y6-Ka for submit@debbugs.gnu.org; Sat, 29 Apr 2023 01:42:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psdLu-0007xq-6r for 62734@debbugs.gnu.org; Sat, 29 Apr 2023 01:42:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psdLn-00080G-BQ; Sat, 29 Apr 2023 01:42:28 -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=7lAOvimLrTFRPz7iGJWS4/jwr4Bq+LLlYxKXVQCD/7Y=; b=NOGw6M8gJZiI 6LB6IAizK7QzNXxLIQQZf/ckyDF9Z55JEIO7/AMbStg6BvpA78MPapcne+HarpWfEHRjAv53r15fH nxdb6LLaXZvKirrc32NRMIRUy6gONd4uty61PZ7uXUot1lK3IKTrRwX80KhSCxfxkfnhdMkoHwdMG Vz9W1f+UrtqLuSakU6gL0VBk7BDquMMdP9xflll8a4/3reocqhfvZFrblxg/S+iMjglqc8VwGa6c1 jvc3wqpDHSw2q19Kim7xV6PJwjVv279V2Mx3L75nOp2QutGIjZ9zAk0YMjonN6uTtD+fHczM5wEVz DooctR1yvez9Fs5jhZvX6g==; Received: from [87.69.77.57] (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 1psdLj-0004EA-Ta; Sat, 29 Apr 2023 01:42:24 -0400 Date: Sat, 29 Apr 2023 08:43:00 +0300 Message-Id: <83mt2rqm57.fsf@gnu.org> From: Eli Zaretskii To: Philip Kaludercic In-Reply-To: <87fs8jg93g.fsf@posteo.net> (message from Philip Kaludercic on Fri, 28 Apr 2023 18:22:43 +0000) Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Philip Kaludercic > Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org > Date: Fri, 28 Apr 2023 18:22:43 +0000 > > Eli Zaretskii writes: > > > What is meant by "building the package"? Is it just compiling the > > Lisp files? > > >From `package-vc-rebuild': > > Rebuilding an installation means scraping for new autoload > cookies, re-compiling Emacs Lisp files, building and installing > any documentation, downloading any missing dependencies. Thanks. As a tangent: this is confusing terminology, so it is unfortunate that it was selected for this operation. > >> (time-less-p output-time > >> (file-attribute-modification-time > >> (file-attributes file))) > >> --8<---------------cut here---------------end--------------->8--- > >> > >> does not hold > > > > Why would it not hold? Updating from VCS should update the timestamp > > of the updated files. > > I don't think this necessarily holds if there were no changes affecting > a file. I don't follow: a file that didn't change doesn't need its autoloads updated, right? > >> Another idea is just to get rid of this faulty optimisation. From my > >> tests this would also resolve the bug. > > > > I don't yet understand what optimization is that, but getting rid of > > it should not alter what the code does for the loaddefs files inside > > the Emacs tree, because there it does work, and I don't want to touch > > that. > > Are you sure it does work? It works well in the Emacs tree, I'm sure. So if it doesn't in this case, I'd encourage some debugging, because it could be that this is some subtle bug or feature in loaddefs-generate, and we should investigate that and fix whatever needs fixing now, since this function is new in Emacs 29. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 29 04:19:16 2023 Received: (at 62734) by debbugs.gnu.org; 29 Apr 2023 08:19:16 +0000 Received: from localhost ([127.0.0.1]:35175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psfnX-0000HZ-At for submit@debbugs.gnu.org; Sat, 29 Apr 2023 04:19:15 -0400 Received: from mout02.posteo.de ([185.67.36.66]:53031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psfnT-0000HI-04 for 62734@debbugs.gnu.org; Sat, 29 Apr 2023 04:19:13 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id EBD07240287 for <62734@debbugs.gnu.org>; Sat, 29 Apr 2023 10:19:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682756345; bh=higtTOzPzwHhNyxXeMCEsXypJ30YvFHtO2xfm5x3QG4=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=GPhf9TrF0vQzW706uR/kySX4Sj4aXl2AK61i1IkdjzDhyvjZoEHYcrhxogPbyH+g5 Hdp613QBeWANScMUAn0AH9kwyoKOiPT9qTkAS4ww4R3QxMGSSzg67V+3AP7hs4mdHv XnybhpFRe+Q6Z2s3Mw3ta85JOHN+FX0R/ohV+n+fdMA2x8ZYYMsf64b+Y55cJachA/ s7dkuFNrA6zNbac8zTXwxtTJ1LUyfrYM3L6A/QXtGMy1m0LKmbGc9+29J2HjslVsxX U66pkyPp/akR05cwcyLS9hVb1O7QOzu0hTzvPtlVcstso41bZh2JgRYC8TkBRVaoKt 2r2XGirM0iqlQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7j6t696kz6twS; Sat, 29 Apr 2023 10:19:02 +0200 (CEST) From: Philip Kaludercic To: Eli Zaretskii Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <83mt2rqm57.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 29 Apr 2023 08:43:00 +0300") References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> <83mt2rqm57.fsf@gnu.org> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Sat, 29 Apr 2023 08:19:35 +0000 Message-ID: <87354jnlrc.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Fri, 28 Apr 2023 18:22:43 +0000 >> >> Eli Zaretskii writes: >> >> > What is meant by "building the package"? Is it just compiling the >> > Lisp files? >> >> >From `package-vc-rebuild': >> >> Rebuilding an installation means scraping for new autoload >> cookies, re-compiling Emacs Lisp files, building and installing >> any documentation, downloading any missing dependencies. > > Thanks. As a tangent: this is confusing terminology, so it is > unfortunate that it was selected for this operation. Is there a different way you would have put this? What we do here is sort of combining the steps that the ELPA server and a local package-install do into one, and in my mind this constitutes building software. >> >> (time-less-p output-time >> >> (file-attribute-modification-time >> >> (file-attributes file))) >> >> --8<---------------cut here---------------end--------------->8--- >> >> >> >> does not hold >> > >> > Why would it not hold? Updating from VCS should update the timestamp >> > of the updated files. >> >> I don't think this necessarily holds if there were no changes affecting >> a file. > > I don't follow: a file that didn't change doesn't need its autoloads > updated, right? Right, but if we want to add some additional code to the autoloads (as we are with package.el, when injecting load-path modification), then loaddefs-generate does not re-use the old data, and instead just throws it away and creates a new file with contents of EXTRA-DATA, but without any autoload information. And I have checked, the only place where `loaddefs-generate' is invoked with EXTRA-DATA, is in `package-generate-autoloads'. So the fact that all other places where this function work as intended makes sense. >> >> Another idea is just to get rid of this faulty optimisation. From my >> >> tests this would also resolve the bug. >> > >> > I don't yet understand what optimization is that, but getting rid of >> > it should not alter what the code does for the loaddefs files inside >> > the Emacs tree, because there it does work, and I don't want to touch >> > that. >> >> Are you sure it does work? > > It works well in the Emacs tree, I'm sure. So if it doesn't in this > case, I'd encourage some debugging, because it could be that this is > some subtle bug or feature in loaddefs-generate, and we should > investigate that and fix whatever needs fixing now, since this > function is new in Emacs 29. I think the central issue here is the (and (not defs) extra-data) check. Just because we did not find any new definitions to autoload /and/ EXTRA-DATA is non-nil, does not mean the old contents should be discarded. The else-case already does the right thing, so I really do think that getting rid of the `if' could resolve the issue: --=-=-= Content-Type: text/plain Content-Disposition: inline diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el index 1007be62dd9..8da0795870c 100644 --- a/lisp/emacs-lisp/loaddefs-gen.el +++ b/lisp/emacs-lisp/loaddefs-gen.el @@ -597,73 +597,64 @@ loaddefs-generate defs)))))) (progress-reporter-done progress)) - ;; If we have no autoloads data, but we have EXTRA-DATA, then - ;; generate the (almost) empty file anyway. - (if (and (not defs) extra-data) + ;; We have some data, so generate the loaddef files. First + ;; group per output file. + (dolist (fdefs (seq-group-by (lambda (x) (expand-file-name (car x))) + defs)) + (let ((loaddefs-file (car fdefs)) + hash) (with-temp-buffer - (insert (loaddefs-generate--rubric output-file nil t)) - (search-backward "\f") - (insert extra-data) - (ensure-empty-lines 1) - (write-region (point-min) (point-max) output-file nil 'silent)) - ;; We have some data, so generate the loaddef files. First - ;; group per output file. - (dolist (fdefs (seq-group-by (lambda (x) (expand-file-name (car x))) - defs)) - (let ((loaddefs-file (car fdefs)) - hash) - (with-temp-buffer - (if (and updating (file-exists-p loaddefs-file)) - (insert-file-contents loaddefs-file) - (insert (loaddefs-generate--rubric - loaddefs-file nil t include-package-version)) - (search-backward "\f") - (when extra-data - (insert extra-data) - (ensure-empty-lines 1))) - (setq hash (buffer-hash)) - ;; Then group by source file (and sort alphabetically). - (dolist (section (sort (seq-group-by #'cadr (cdr fdefs)) - (lambda (e1 e2) - (string< - (file-name-sans-extension - (file-name-nondirectory (car e1))) - (file-name-sans-extension - (file-name-nondirectory (car e2))))))) - (pop section) - (let* ((relfile (file-relative-name - (cadar section) - (file-name-directory loaddefs-file))) - (head (concat "\n\f\n;;; Generated autoloads from " - relfile "\n\n"))) - (when (file-exists-p loaddefs-file) - ;; If we're updating an old loaddefs file, then see if - ;; there's a section here for this file already. - (goto-char (point-min)) - (if (not (search-forward head nil t)) - ;; It's a new file; put the data at the end. - (progn - (goto-char (point-max)) - (search-backward "\f\n" nil t)) - ;; Delete the old version of the section. - (delete-region (match-beginning 0) - (and (search-forward "\n\f\n;;;") - (match-beginning 0))) - (forward-line -2))) - (insert head) - (dolist (def (reverse section)) - (setq def (caddr def)) - (if (stringp def) - (princ def (current-buffer)) - (loaddefs-generate--print-form def)) - (unless (bolp) - (insert "\n"))))) - ;; Only write the file if we actually made a change. - (unless (equal (buffer-hash) hash) - (write-region (point-min) (point-max) loaddefs-file nil 'silent) - (byte-compile-info - (file-relative-name loaddefs-file (car (ensure-list dir))) - t "GEN")))))))) + (if (and updating (file-exists-p loaddefs-file)) + (insert-file-contents loaddefs-file) + (insert (loaddefs-generate--rubric + loaddefs-file nil t include-package-version)) + (search-backward "\f") + (when extra-data + (insert extra-data) + (ensure-empty-lines 1))) + (setq hash (buffer-hash)) + ;; Then group by source file (and sort alphabetically). + (dolist (section (sort (seq-group-by #'cadr (cdr fdefs)) + (lambda (e1 e2) + (string< + (file-name-sans-extension + (file-name-nondirectory (car e1))) + (file-name-sans-extension + (file-name-nondirectory (car e2))))))) + (pop section) + (let* ((relfile (file-relative-name + (cadar section) + (file-name-directory loaddefs-file))) + (head (concat "\n\f\n;;; Generated autoloads from " + relfile "\n\n"))) + (when (file-exists-p loaddefs-file) + ;; If we're updating an old loaddefs file, then see if + ;; there's a section here for this file already. + (goto-char (point-min)) + (if (not (search-forward head nil t)) + ;; It's a new file; put the data at the end. + (progn + (goto-char (point-max)) + (search-backward "\f\n" nil t)) + ;; Delete the old version of the section. + (delete-region (match-beginning 0) + (and (search-forward "\n\f\n;;;") + (match-beginning 0))) + (forward-line -2))) + (insert head) + (dolist (def (reverse section)) + (setq def (caddr def)) + (if (stringp def) + (princ def (current-buffer)) + (loaddefs-generate--print-form def)) + (unless (bolp) + (insert "\n"))))) + ;; Only write the file if we actually made a change. + (unless (equal (buffer-hash) hash) + (write-region (point-min) (point-max) loaddefs-file nil 'silent) + (byte-compile-info + (file-relative-name loaddefs-file (car (ensure-list dir))) + t "GEN"))))))) (defun loaddefs-generate--print-form (def) "Print DEF in a format that makes sense for version control." --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 29 06:31:46 2023 Received: (at 62734) by debbugs.gnu.org; 29 Apr 2023 10:31:46 +0000 Received: from localhost ([127.0.0.1]:35288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pshrm-0007G1-8I for submit@debbugs.gnu.org; Sat, 29 Apr 2023 06:31:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pshrj-0007Fj-5C for 62734@debbugs.gnu.org; Sat, 29 Apr 2023 06:31:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pshrb-0006wa-Tb; Sat, 29 Apr 2023 06:31:35 -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=npWIU+BR0X7oMV9uXy+U9+w9yoDVXmjZ7EdFdEBY+Zo=; b=DYQdXxVt8TdJ 2N6jXXKjiTXQjS7f+kuhofjfwGFJqxufoEKfT4qv+xiylqq3KEWK9Qx4RcPwhQu8vDJP9gvtnGRWT F5ACz0GW8IASV4/fnQkHCVROCV0s/nubJBRbgDXiXlai30zYyzORuIdzkagX4J+pxGC/XpUhQX/vS K4ybGAO6WkepzW4vzm1uBtRHLyp6OyYQUW8qzgLiJwwCbrdRfe2/0wzchA3cyvQj3Rvbh38mQJhFk 7udTW/itXnP8JgPxBIMsZF+CUxTqmUBQ23ic7lqek6JU/G5kaJnbb/Lx4N8pfzbN7tw+oVH1IRjXr pqtA7zUGB2aiKUEExxskXQ==; Received: from [87.69.77.57] (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 1pshra-0000Il-Rr; Sat, 29 Apr 2023 06:31:35 -0400 Date: Sat, 29 Apr 2023 13:32:11 +0300 Message-Id: <83y1mbou6s.fsf@gnu.org> From: Eli Zaretskii To: Philip Kaludercic In-Reply-To: <87354jnlrc.fsf@posteo.net> (message from Philip Kaludercic on Sat, 29 Apr 2023 08:19:35 +0000) Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> <83mt2rqm57.fsf@gnu.org> <87354jnlrc.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Philip Kaludercic > Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org > Date: Sat, 29 Apr 2023 08:19:35 +0000 > > >> Rebuilding an installation means scraping for new autoload > >> cookies, re-compiling Emacs Lisp files, building and installing > >> any documentation, downloading any missing dependencies. > > > > Thanks. As a tangent: this is confusing terminology, so it is > > unfortunate that it was selected for this operation. > > Is there a different way you would have put this? What we do here is > sort of combining the steps that the ELPA server and a local > package-install do into one, and in my mind this constitutes building > software. Compilation? Setup? "Building" is a strange term when we are talking about a Lisp package. > > I don't follow: a file that didn't change doesn't need its autoloads > > updated, right? > > Right, but if we want to add some additional code to the autoloads (as > we are with package.el, when injecting load-path modification), then > loaddefs-generate does not re-use the old data, and instead just throws > it away and creates a new file with contents of EXTRA-DATA, but without > any autoload information. That is definitely a bug. But a package without autoloads is still a valid use case, and we should support it. > I think the central issue here is the > > (and (not defs) extra-data) > > check. Just because we did not find any new definitions to autoload > /and/ EXTRA-DATA is non-nil, does not mean the old contents should be > discarded. The else-case already does the right thing, so I really do > think that getting rid of the `if' could resolve the issue: What happens if a package has no autoloads? The doc string says in that case passing EXTRA-DATA will produce OUTPUT-FILE regardless. Does your patch handle that? (It's hard to tell, given all the whitespace changes in the patch.) From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 29 07:18:04 2023 Received: (at 62734) by debbugs.gnu.org; 29 Apr 2023 11:18:04 +0000 Received: from localhost ([127.0.0.1]:35331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psiaZ-0000J6-To for submit@debbugs.gnu.org; Sat, 29 Apr 2023 07:18:04 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57669) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psiaW-0000IU-0s for 62734@debbugs.gnu.org; Sat, 29 Apr 2023 07:18:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C38FF2403B0 for <62734@debbugs.gnu.org>; Sat, 29 Apr 2023 13:17:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682767073; bh=cjgk/LW+kJ1GC98QmvGbR5Wpgn2w+MPLy9pFepYOudU=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=NTdupO+LF+mPDLOAq2UMjhgc1NimzmlvLZKvcKCFEXSTE1DML5xsnfsu94vScG2+Q 9AmvsyPGyeo/IEYSjf5LECTgYaG76xpGVYLnfWQ6/EF1NiUfB1Wir0Fw/T0Xco39bc jUq9IpSbvTeXMNvItsMREsEske3FzCU3NOE87NSXUpXeioeKAFWfTZa5T50qDLI6rM VoWx+MaMJprVye4yMQ5UFbhkmE8MkebrOT4M3E9rbD2BRx/V49hyn9dRhXmPLIiXUl JBE97gyNZPpVzjU31F26BMo9whPxSB46/MOAgo3PSXUDB8QIRKTs4tYYk1W9WzQI+D /Zcx77i2XmiBQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7n5F0qVXz6tn4; Sat, 29 Apr 2023 13:17:52 +0200 (CEST) From: Philip Kaludercic To: Eli Zaretskii Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <83y1mbou6s.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 29 Apr 2023 13:32:11 +0300") References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> <83mt2rqm57.fsf@gnu.org> <87354jnlrc.fsf@posteo.net> <83y1mbou6s.fsf@gnu.org> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Sat, 29 Apr 2023 11:18:25 +0000 Message-ID: <874jozym0u.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Sat, 29 Apr 2023 08:19:35 +0000 >> >> >> Rebuilding an installation means scraping for new autoload >> >> cookies, re-compiling Emacs Lisp files, building and installing >> >> any documentation, downloading any missing dependencies. >> > >> > Thanks. As a tangent: this is confusing terminology, so it is >> > unfortunate that it was selected for this operation. >> >> Is there a different way you would have put this? What we do here is >> sort of combining the steps that the ELPA server and a local >> package-install do into one, and in my mind this constitutes building >> software. > > Compilation? Setup? Scraping for auto-loads doesn't have anything to do with "compiling" (and might be confused with byte compilation). "Setup" might be imaginable, I will think about it. > "Building" is a strange term when we are talking about a Lisp package. How come? >> > I don't follow: a file that didn't change doesn't need its autoloads >> > updated, right? >> >> Right, but if we want to add some additional code to the autoloads (as >> we are with package.el, when injecting load-path modification), then >> loaddefs-generate does not re-use the old data, and instead just throws >> it away and creates a new file with contents of EXTRA-DATA, but without >> any autoload information. > > That is definitely a bug. But a package without autoloads is still a > valid use case, and we should support it. > >> I think the central issue here is the >> >> (and (not defs) extra-data) >> >> check. Just because we did not find any new definitions to autoload >> /and/ EXTRA-DATA is non-nil, does not mean the old contents should be >> discarded. The else-case already does the right thing, so I really do >> think that getting rid of the `if' could resolve the issue: > > What happens if a package has no autoloads? The doc string says in > that case passing EXTRA-DATA will produce OUTPUT-FILE regardless. > Does your patch handle that? (It's hard to tell, given all the > whitespace changes in the patch.) It would, as the else-case of the if branch I am proposing to eliminate would still insert the EXTRA-DATA. Here is a patch generated without any whitespace changes: --=-=-= Content-Type: text/plain Content-Disposition: inline diff --git a/lisp/emacs-lisp/loaddefs-gen.el b/lisp/emacs-lisp/loaddefs-gen.el index 1007be62dd9..8da0795870c 100644 --- a/lisp/emacs-lisp/loaddefs-gen.el +++ b/lisp/emacs-lisp/loaddefs-gen.el @@ -597,15 +597,6 @@ loaddefs-generate defs)))))) (progress-reporter-done progress)) - ;; If we have no autoloads data, but we have EXTRA-DATA, then - ;; generate the (almost) empty file anyway. - (if (and (not defs) extra-data) - (with-temp-buffer - (insert (loaddefs-generate--rubric output-file nil t)) - (search-backward "\f") - (insert extra-data) - (ensure-empty-lines 1) - (write-region (point-min) (point-max) output-file nil 'silent)) ;; We have some data, so generate the loaddef files. First ;; group per output file. (dolist (fdefs (seq-group-by (lambda (x) (expand-file-name (car x))) @@ -663,7 +654,7 @@ loaddefs-generate (write-region (point-min) (point-max) loaddefs-file nil 'silent) (byte-compile-info (file-relative-name loaddefs-file (car (ensure-list dir))) - t "GEN")))))))) + t "GEN"))))))) (defun loaddefs-generate--print-form (def) "Print DEF in a format that makes sense for version control." --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 29 08:21:19 2023 Received: (at 62734) by debbugs.gnu.org; 29 Apr 2023 12:21:19 +0000 Received: from localhost ([127.0.0.1]:35380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psjZn-0004k8-Gq for submit@debbugs.gnu.org; Sat, 29 Apr 2023 08:21:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psjZl-0004js-H2 for 62734@debbugs.gnu.org; Sat, 29 Apr 2023 08:21:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psjZe-0005tR-VM; Sat, 29 Apr 2023 08:21:10 -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=fjapmyiQziOvx2kWB4Yelcbg2DRfBzrm3mJ9+DsiyJ8=; b=AggG8PAppGto bbByTXbQqhS4MYqpzFsI9CeDdPImMuT+8sG+R5W5/WUX6qCo/5UTfR+SKFjtEEl7BBfXWpVokJBTu zO8YHfbDI8Ihl7ZRD3KlCrcukHG2rrXLgm3JNSwCDrRrjt2eA5u+3HFJSeYAFZ2poXeYJP+khoZUN 6Sk1L/eUIoVv/LhgfmwMNWAlvqkCmXxcYAgtbJTmUzCIxJVqsvqu8Y/5Pu8nrJFVVjddNXNM1heTr lVyq2Y9pscU2SQzvLD/K2eKXsDO+yyuxH7mdMgFHfu23VXrl5Ppw4auA81wtDM6J3JYW0pruJ5Zcv bBX36lULztlJtz7xd73uFQ==; Received: from [87.69.77.57] (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 1psjZd-0000Sn-Vl; Sat, 29 Apr 2023 08:21:10 -0400 Date: Sat, 29 Apr 2023 15:21:47 +0300 Message-Id: <83r0s2q3ok.fsf@gnu.org> From: Eli Zaretskii To: Philip Kaludercic In-Reply-To: <874jozym0u.fsf@posteo.net> (message from Philip Kaludercic on Sat, 29 Apr 2023 11:18:25 +0000) Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> <83mt2rqm57.fsf@gnu.org> <87354jnlrc.fsf@posteo.net> <83y1mbou6s.fsf@gnu.org> <874jozym0u.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Philip Kaludercic > Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org > Date: Sat, 29 Apr 2023 11:18:25 +0000 > > > "Building" is a strange term when we are talking about a Lisp package. > > How come? There's nothing to "build". Everything is already built. > >> I think the central issue here is the > >> > >> (and (not defs) extra-data) > >> > >> check. Just because we did not find any new definitions to autoload > >> /and/ EXTRA-DATA is non-nil, does not mean the old contents should be > >> discarded. The else-case already does the right thing, so I really do > >> think that getting rid of the `if' could resolve the issue: > > > > What happens if a package has no autoloads? The doc string says in > > that case passing EXTRA-DATA will produce OUTPUT-FILE regardless. > > Does your patch handle that? (It's hard to tell, given all the > > whitespace changes in the patch.) > > It would, as the else-case of the if branch I am proposing to eliminate > would still insert the EXTRA-DATA. And if EXTRA-DATA is nil, then will we generate an empty OUTPUT file? From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 30 05:16:58 2023 Received: (at 62734) by debbugs.gnu.org; 30 Apr 2023 09:16:58 +0000 Received: from localhost ([127.0.0.1]:37186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pt3Av-0005hn-VO for submit@debbugs.gnu.org; Sun, 30 Apr 2023 05:16:58 -0400 Received: from mout01.posteo.de ([185.67.36.65]:57575) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pt3Ar-0005hX-2U for 62734@debbugs.gnu.org; Sun, 30 Apr 2023 05:16:56 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 35188240195 for <62734@debbugs.gnu.org>; Sun, 30 Apr 2023 11:16:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682846207; bh=MAnPEiSxAhUbjydQgU+Oj5XX8jI6ydPR7BL4IYRazaA=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=XXKaoV062BeQAkmZpMcVS/wYUIrdUyTYBVCOu2FplkTMcdFVZ7HNs+pRiJXQsauaZ 3KASkxwIxNVvtWuD4G9Qx+vJocvOD9f+G0Ur0S7HDKD9pzPLKe4Cfo2iryd3Vf6WNW 8u8abV8cBZaL3yBVcIlIdPLl44fcoYer/fVnDBK/nUMGaUXAwsS7sv7h5WBufVSQb/ VNtjBG0pUzruLTfvh9iKjRJOZSKFu+55YuahpvNaRu7IqpQEFQG+e9a9tb0B7r0noJ E31dSPI7RjOpeFcpecu5etWqB93h1h6WHv6n4E3X8OvhovijI+8NesY/i092Fg8XMX FKOynciz8RRnQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q8LM02tzwz9rxM; Sun, 30 Apr 2023 11:16:44 +0200 (CEST) From: Philip Kaludercic To: Eli Zaretskii Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <83r0s2q3ok.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 29 Apr 2023 15:21:47 +0300") References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> <83mt2rqm57.fsf@gnu.org> <87354jnlrc.fsf@posteo.net> <83y1mbou6s.fsf@gnu.org> <874jozym0u.fsf@posteo.net> <83r0s2q3ok.fsf@gnu.org> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Sun, 30 Apr 2023 09:17:16 +0000 Message-ID: <87jzxtg25f.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Sat, 29 Apr 2023 11:18:25 +0000 >> >> > "Building" is a strange term when we are talking about a Lisp package. >> >> How come? > > There's nothing to "build". Everything is already built. The idea is that this mirrors the building of a tarball on the ELPA server, but as I said, I will think about this matter. >> >> I think the central issue here is the >> >> >> >> (and (not defs) extra-data) >> >> >> >> check. Just because we did not find any new definitions to autoload >> >> /and/ EXTRA-DATA is non-nil, does not mean the old contents should be >> >> discarded. The else-case already does the right thing, so I really do >> >> think that getting rid of the `if' could resolve the issue: >> > >> > What happens if a package has no autoloads? The doc string says in >> > that case passing EXTRA-DATA will produce OUTPUT-FILE regardless. >> > Does your patch handle that? (It's hard to tell, given all the >> > whitespace changes in the patch.) >> >> It would, as the else-case of the if branch I am proposing to eliminate >> would still insert the EXTRA-DATA. > > And if EXTRA-DATA is nil, then will we generate an empty OUTPUT file? No, we still generate the right file with the right information (in this case just a `register-definition-prefixes' invocation). From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 30 06:08:03 2023 Received: (at 62734) by debbugs.gnu.org; 30 Apr 2023 10:08:03 +0000 Received: from localhost ([127.0.0.1]:37256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pt3yN-0007JI-BW for submit@debbugs.gnu.org; Sun, 30 Apr 2023 06:08:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pt3yI-0007Ii-Qu for 62734@debbugs.gnu.org; Sun, 30 Apr 2023 06:08:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pt3yD-0002f0-0J; Sun, 30 Apr 2023 06:07:53 -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=iSnSnmtBozFyhAxwtdNTl+PuBiyOAJY/05L6Gx5SesU=; b=Nz8ip29OtVPU sYURba8SsO6F1qbE8dWUayAgaCFUYl5l9qDtlzz5clqr1BQcVh91TbCC9sfk3iwj9VjViN2Urm9jC zvOx6RcLfsmQTxRNDKc3vaWIX7UJLLpJM+GxPV0Wxfbu0Jo6b84KSoUVyfAy0oa1VV7DqBwZr7V9w C4IPvnhTeUw5RtizG5jdj8aHJlpKZdt7sgmIiQMqerqRjZ+3pj1kWg2Jf6OB0EyiyDJQd3g/Q4yOY CJFwi2cJm9AdsLT12MN1pAnyDZpI8EwHN6nKrjR9Pq86xYJMEefFwT8kIeMG8iLIMFUADwT0dEnV5 KGtyH8LUXlZp2/1YGXjNPg==; Received: from [87.69.77.57] (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 1pt3yB-0002Di-S7; Sun, 30 Apr 2023 06:07:52 -0400 Date: Sun, 30 Apr 2023 13:08:31 +0300 Message-Id: <83h6sxptr4.fsf@gnu.org> From: Eli Zaretskii To: Philip Kaludercic In-Reply-To: <87jzxtg25f.fsf@posteo.net> (message from Philip Kaludercic on Sun, 30 Apr 2023 09:17:16 +0000) Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> <83mt2rqm57.fsf@gnu.org> <87354jnlrc.fsf@posteo.net> <83y1mbou6s.fsf@gnu.org> <874jozym0u.fsf@posteo.net> <83r0s2q3ok.fsf@gnu.org> <87jzxtg25f.fsf@posteo.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734 Cc: 62734@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Philip Kaludercic > Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org > Date: Sun, 30 Apr 2023 09:17:16 +0000 > > Eli Zaretskii writes: > > >> > What happens if a package has no autoloads? The doc string says in > >> > that case passing EXTRA-DATA will produce OUTPUT-FILE regardless. > >> > Does your patch handle that? (It's hard to tell, given all the > >> > whitespace changes in the patch.) > >> > >> It would, as the else-case of the if branch I am proposing to eliminate > >> would still insert the EXTRA-DATA. > > > > And if EXTRA-DATA is nil, then will we generate an empty OUTPUT file? > > No, we still generate the right file with the right information (in this > case just a `register-definition-prefixes' invocation). OK, thanks. Then please make sure this change survives both a bootstrap and a "normal" build (where a bunch of *.el files need their autoloads updated), and if so, please install on the emacs-29 branch. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 30 12:44:50 2023 Received: (at 62734-done) by debbugs.gnu.org; 30 Apr 2023 16:44:50 +0000 Received: from localhost ([127.0.0.1]:38306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ptAAL-0007I6-Nj for submit@debbugs.gnu.org; Sun, 30 Apr 2023 12:44:50 -0400 Received: from mout02.posteo.de ([185.67.36.66]:60289) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ptAAJ-0007Ho-A0 for 62734-done@debbugs.gnu.org; Sun, 30 Apr 2023 12:44:48 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 62F202401FF for <62734-done@debbugs.gnu.org>; Sun, 30 Apr 2023 18:44:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682873081; bh=gc3z/qDr1imAZzpKeMeLobpx7rCSfrbgxBJfPKmug3s=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=dTtuqW4tPq9dBejA5QrqG+FcAbpa+MtGFtBWL6m3Y13/pT2DqcQXn6qrUwVSlMyQk ajo290dyTEUZiwL63fwy8Bi+yJ3Pt/l+HYclKz2o6bwELUah1WHaonEkXmk7qIlxVG dDiXaOeSOZQqJbQQq1HSXFrqJB1XzWjxwcgGEJ4NwqE8AgetXBOjTfKkS4bevb6F2l H3TO/43V2jf2LVLqxhk8NFNxU/t0U9z2DBoM9FXHnTXXPsvLv6Va9nGeVWPXrWSM3I Wp29YoJVNl2ZPQx7FXdkWAxJj1EMC09bntihx2aDyTNVlPVVDInOV+azzgZxDfrn6N iR8UhK5G9yEFw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q8XHr14KGz6tvm; Sun, 30 Apr 2023 18:44:40 +0200 (CEST) From: Philip Kaludercic To: Eli Zaretskii Subject: Re: bug#62734: Always fully rebuild autoloads in package-generate-autoloads In-Reply-To: <83h6sxptr4.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 30 Apr 2023 13:08:31 +0300") References: <87lej2oz14.fsf@le0.gs> <874jp0aw7h.fsf@posteo.net> <83pm7oqa7d.fsf@gnu.org> <87o7n7ga4x.fsf@posteo.net> <83o7n7ri64.fsf@gnu.org> <87fs8jg93g.fsf@posteo.net> <83mt2rqm57.fsf@gnu.org> <87354jnlrc.fsf@posteo.net> <83y1mbou6s.fsf@gnu.org> <874jozym0u.fsf@posteo.net> <83r0s2q3ok.fsf@gnu.org> <87jzxtg25f.fsf@posteo.net> <83h6sxptr4.fsf@gnu.org> Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Date: Sun, 30 Apr 2023 16:45:12 +0000 Message-ID: <87wn1tuxnr.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62734-done Cc: 62734-done@debbugs.gnu.org, leo.gaskin@le0.gs X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> From: Philip Kaludercic >> Cc: leo.gaskin@le0.gs, 62734@debbugs.gnu.org >> Date: Sun, 30 Apr 2023 09:17:16 +0000 >> >> Eli Zaretskii writes: >> >> >> > What happens if a package has no autoloads? The doc string says in >> >> > that case passing EXTRA-DATA will produce OUTPUT-FILE regardless. >> >> > Does your patch handle that? (It's hard to tell, given all the >> >> > whitespace changes in the patch.) >> >> >> >> It would, as the else-case of the if branch I am proposing to eliminate >> >> would still insert the EXTRA-DATA. >> > >> > And if EXTRA-DATA is nil, then will we generate an empty OUTPUT file? >> >> No, we still generate the right file with the right information (in this >> case just a `register-definition-prefixes' invocation). > > OK, thanks. Then please make sure this change survives both a > bootstrap and a "normal" build (where a bunch of *.el files need their > autoloads updated), and if so, please install on the emacs-29 branch. Done, I have been testing it for a better part of the day and from what I saw all behaved the way it should. Thanks to Leo for noticing the problem in the first place, package-vc also appears to be doing the right thing now. From unknown Sun Jun 22 03:58:00 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 29 May 2023 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator