From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master add49b6: * lisp/emacs-lisp/package.el: Reduce autoloading before compiling Date: Tue, 08 Sep 2015 09:46:30 -0400 Message-ID: References: <20150907225246.18328.36154@vcs.savannah.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441720022 12130 80.91.229.3 (8 Sep 2015 13:47:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Sep 2015 13:47:02 +0000 (UTC) Cc: emacs-devel To: Artur Malabarba Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 08 15:46:50 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZZJEM-0000Q6-W8 for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 15:46:39 +0200 Original-Received: from localhost ([::1]:34254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZJEN-0000iW-5t for ged-emacs-devel@m.gmane.org; Tue, 08 Sep 2015 09:46:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZJEJ-0000hJ-1V for emacs-devel@gnu.org; Tue, 08 Sep 2015 09:46:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZJEF-0001Ll-Qe for emacs-devel@gnu.org; Tue, 08 Sep 2015 09:46:34 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:44177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZJEF-0001Kz-M7 for emacs-devel@gnu.org; Tue, 08 Sep 2015 09:46:31 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtCwA731xV/5Wg+M5cgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQMBViMFCwsOJhIUGA0kiDcIzyMBAQEBBgIBH4s6hQUHhC0Fi0SOKgWZTIFFI4FmJBwVgVkigngBAQE X-IPAS-Result: A0CtCwA731xV/5Wg+M5cgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQMBViMFCwsOJhIUGA0kiDcIzyMBAQEBBgIBH4s6hQUHhC0Fi0SOKgWZTIFFI4FmJBwVgVkigngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="162897274" Original-Received: from 206-248-160-149.dsl.teksavvy.com (HELO pastel.home) ([206.248.160.149]) by ironport2-out.teksavvy.com with ESMTP; 08 Sep 2015 09:46:30 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4D7F96040C; Tue, 8 Sep 2015 09:46:30 -0400 (EDT) In-Reply-To: (Artur Malabarba's message of "Tue, 8 Sep 2015 02:59:20 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189711 Archived-At: > IIUC, there are only two things in package-activate-1 that affect > byte-compilation: setting the load-path and loading the autoloads > file. Hmm... I think that "Call `load' on all files in `pkg-dir' already present in `load-history'" would also affect compilation, so it should be in package--activate-autoloads-and-load-path. > 1) `package-activate-1' has a couple of line that shouldn't be called > twice, like (push name package-activated-list) and (push pkg-dir > Info-directory-list). They should be fixed to be idempotent since that can happen in any case if the package was activated and then gets updated (and hence re-activated). > 2) It's just confusing to see a package being activated twice > throughout a single installation. I find it more informative to do > specifically what we want (i.e., load autloads and set load-path > before compilation). That makes sense. I think compilation is a separate step which should be optional (and as mentioned elsewhere, we should have a command to perform (re)compilation of a package separately afterwards). So the presence of two "activation" calls is legitimate (the one for compilation is needed if the package was not activated yet, and the other is needed if compilation did not happen). But I wonder why they should be different. Can't we just have the "non-compilation activation" be performed before compilation takes place, and then change compilation so that it only activates the package if that was not done yet? Stefan