From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.bugs Subject: bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation Date: Thu, 24 Nov 2011 22:52:26 +0530 Message-ID: <81ipm9l9kd.fsf__9484.23061422563$1322155420$gmane$org@gmail.com> References: <81pqgh90sp.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1322155420 28496 80.91.229.12 (24 Nov 2011 17:23:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 24 Nov 2011 17:23:40 +0000 (UTC) Cc: 10125@debbugs.gnu.org, emacs-orgmode@gnu.org, stelian.iancu@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 24 18:23:35 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RTd1L-00024I-Ih for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Nov 2011 18:23:35 +0100 Original-Received: from localhost ([::1]:34782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTd1K-0004Qb-2L for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Nov 2011 12:23:34 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:38846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTd1H-0004QW-1M for bug-gnu-emacs@gnu.org; Thu, 24 Nov 2011 12:23:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RTd1F-00021v-V8 for bug-gnu-emacs@gnu.org; Thu, 24 Nov 2011 12:23:31 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RTd1F-00021r-SO for bug-gnu-emacs@gnu.org; Thu, 24 Nov 2011 12:23:29 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RTd2j-0003NH-Pp for bug-gnu-emacs@gnu.org; Thu, 24 Nov 2011 12:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jambunathan K Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Nov 2011 17:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10125 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10125-submit@debbugs.gnu.org id=B10125.132215546812933 (code B ref 10125); Thu, 24 Nov 2011 17:25:01 +0000 Original-Received: (at 10125) by debbugs.gnu.org; 24 Nov 2011 17:24:28 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RTd2C-0003MX-7b for submit@debbugs.gnu.org; Thu, 24 Nov 2011 12:24:28 -0500 Original-Received: from mail-iy0-f172.google.com ([209.85.210.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RTd26-0003MN-KP for 10125@debbugs.gnu.org; Thu, 24 Nov 2011 12:24:24 -0500 Original-Received: by iaeo4 with SMTP id o4so3228097iae.3 for <10125@debbugs.gnu.org>; Thu, 24 Nov 2011 09:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=Rd2zdtAzDBv16ZEngfYiNsBXnRfdS3in6OnQi4Y29so=; b=JBVUJ6Js5erHJcf/33c+0wH2nzZ7cqZtCF8jgo3cIW5dmsIraK//5zHR/YlFv+YjVu iEfF/sYoUh73VnO2IagyCA2JNfguZly9w7GJVfE1iqd07UlpLXjSKMBrTjzw7c95Va6Z QGrpp7nUecufp5KpNd6m34grQYoArdh3T8mqc= Original-Received: by 10.43.50.67 with SMTP id vd3mr8209152icb.10.1322155369990; Thu, 24 Nov 2011 09:22:49 -0800 (PST) Original-Received: from JAMBU-NETBOOK ([115.241.120.62]) by mx.google.com with ESMTPS id dd36sm89486894ibb.7.2011.11.24.09.22.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Nov 2011 09:22:49 -0800 (PST) In-Reply-To: (Eli Zaretskii's message of "Thu, 24 Nov 2011 08:05:21 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (windows-nt) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 24 Nov 2011 12:25:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:54264 Archived-At: > Org Mode files certainly have no dependency rules in lisp/Makefile.in. The Makefile - in devel repo of Orgmode - does define rules. Read on ... > So the question why the problem does not happen while compiling Org in > Emacs remains. I believe the way the files are compiled makes a substantial difference. When compiling with makefiles: The compilation happens with *minimal* emacs and in batch mode. --8<---------------cut here---------------start------------->8--- BATCH=$(EMACS) -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"$(lispdir)\" load-path)))" --8<---------------cut here---------------end--------------->8--- As can be seen above, any (require 'something) of macro files in the compiled elisp file has to be loaded from the development version itself. Furthermore there are dependencies like this in the Makefile: --8<---------------cut here---------------start------------->8--- lisp/org.elc: lisp/org-macs.el lisp/org-compat.el lisp/org-faces.el lisp/org-agenda.elc: lisp/org.el --8<---------------cut here---------------end--------------->8--- (I believe removing the dependencies from the Makefiles will still do the right thing because of the require directives in the compiled files will load the development version and not the system version) When compiling with package manager, the compilation happens from within a running Emacs session and very likely the "old" Org files are already loaded in to the runtime "inadvertently" by the user either by looking at the org agenda for the day or may be by just viewing an Org file or by the plain old (require 'org-whatever) out of habit in .emacs. While reporting macro issues, users never say whether they were already running Org when they were trying to fetch and compile a new Org. They think it is immaterial. I believe it matters If "old" org and hence "old" org-macs is already loaded in the environment when the package is installed, any subsequent (require 'something) will be essentially no-ops. (Can you confirm this?) What ideally should happen is that during package compilation, a require should *forcibly* load from the compiled package and not merely check for availability of a feature symbol. >> 2. While building from ELPA, the compilation order seems to be >> alphabetical. So the files get compiled bass ackwards. For example, >> org-macs.el gets compiled after org-agenda.el. >> >> In summary, there needs to be a way to specify the order in which files >> are compiled in a multifile tar. > > This was discussed several time, in the context of recompiling > multiple Lisp files while building Emacs, and the decision till now > was to ignore the issue. While at least in principle one could write > a Lisp program that would analyze the various `require' and `load' > calls (possibly as side effect of byte compilation, like GCC does), > and generate Makefile rules with correct prerequisites, this is a > non-trivial project. I have tried giving an explanation in the earlier paragraph. > One simple band-aid is to remove all the *.elc files before > byte-compiling after resync. This prolongs the compilation, but the > results are predictably correct. We are talking of "automatic" compilation by package manager. What you say applies to hand compilation via makefiles. >> A supplementary question to (2): >> >> During the package compilation, when encountering (require >> 'some-org-library-with-macros) does the library get loaded from *within* >> the tarball or from the *emacs core*. > > Whichever is found first along load-path, I think. See `openp'. What does package manager do? --