From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: compilation issues of new export framework Date: Sun, 10 Feb 2013 11:44:20 +0100 Message-ID: <87txpko3cr.fsf@Rainer.invalid> References: <876229nrxf.fsf@gmail.com> <87a9rd3odf.fsf@Rainer.invalid> <87y5ex5rwa.fsf_-_@Rainer.invalid> <877gmhs7f4.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4UOv-0004rw-AN for emacs-orgmode@gnu.org; Sun, 10 Feb 2013 05:44:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U4UOt-0000zu-NT for emacs-orgmode@gnu.org; Sun, 10 Feb 2013 05:44:49 -0500 Received: from plane.gmane.org ([80.91.229.3]:50372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U4UOt-0000yv-GP for emacs-orgmode@gnu.org; Sun, 10 Feb 2013 05:44:47 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U4UP5-0006qm-GN for emacs-orgmode@gnu.org; Sun, 10 Feb 2013 11:44:59 +0100 Received: from pd9eb25de.dip.t-dialin.net ([217.235.37.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Feb 2013 11:44:59 +0100 Received: from Stromeko by pd9eb25de.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Feb 2013 11:44:59 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Yes, I noticed this one too, but I don't know yet from where it could > come from. It comes from the two autoloads, or probably only the second one as the first is later declare-function'ed anyway. If you declare these, then the defsubst get sometimes compiled as function calls and sometimes as inlined functions (the normal mode of compilation inlines them). --8<---------------cut here---------------start------------->8--- diff --git a/lisp/org.el b/lisp/org.el index 2bfca4e..c679c5d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -137,9 +137,6 @@ (defvar org-heading-regexp "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$" (declare-function org-table-maybe-eval-formula "org-table" ()) (declare-function org-table-maybe-recalculate-line "org-table" ()) -(autoload 'org-element-at-point "org-element") -(autoload 'org-element-type "org-element") - (declare-function org-element--parse-objects "org-element" (beg end acc restriction)) (declare-function org-element-at-point "org-element" (&optional keep-trail)) @@ -152,6 +149,7 @@ (defvar org-heading-regexp "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$" (declare-function org-element-nested-p "org-element" (elem-a elem-b)) (declare-function org-element-parse-buffer "org-element" (&optional granularity visible-only)) +(declare-function org-element-type "org-element" (element)) (declare-function org-element-property "org-element" (property element)) (declare-function org-element-put-property "org-element" (element property value)) --8<---------------cut here---------------end--------------->8--- If instead you really want them always replaced with the definition of the defsubst (on the assumption that this is indeed faster than a function call or permits better optimization by the bytecompiler), then these would need to be moved to org.el and their declarations removed. Alternatively the defsubsts could go into a separate file that is then required from both org.el and org-element.el None of these options solve the larger problem of the circular dependencies. PS: If compiled single, four Babel tests fail; three of them with an "(invalid-function org-export-with-buffer-copy)". The function it complains about is actually a macro in ox.el that is used in org-export-as before its definition. Not cool, it must be moved before org-export-as. The tests then pass with a single-compiled version of org. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada