emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jambunathan K <kjambunathan@gmail.com>
Cc: 10125@debbugs.gnu.org, emacs-orgmode@gnu.org, stelian.iancu@gmail.com
Subject: bug#10125: 24.0.91; package.el (org): Macros in tar packages & order of byte compilation
Date: Thu, 24 Nov 2011 08:05:21 -0500	[thread overview]
Message-ID: <E1RTYzR-00039k-Q6@fencepost.gnu.org> (raw)
In-Reply-To: <81pqgh90sp.fsf@gmail.com> (message from Jambunathan K on Thu, 24 Nov 2011 17:42:38 +0530)

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Thu, 24 Nov 2011 17:42:38 +0530
> Cc: emacs-orgmode@gnu.org, Stelian Iancu <stelian.iancu@gmail.com>
> 
> 1. While building via Makefile, there is an implicit dependency that is
> *enforced* via make rules and files with macro definitions are compiled
> ahead of their consumers.

That's not true: there are no dependencies defined in lisp/Makefile.in
in the Emacs source tree for Lisp files, with a very few exceptions.
Org Mode files certainly have no dependency rules in lisp/Makefile.in.
So the question why the problem does not happen while compiling Org in
Emacs remains.

> 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.

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.

> 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'.

  parent reply	other threads:[~2011-11-24 13:05 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87sj68eogm.fsf@Rainer.invalid>
     [not found] ` <mthamoy574.fsf@fencepost.gnu.org>
2013-01-11  1:57   ` bug#10125: RFE: require and load-path-shadowing Stefan Monnier
     [not found]   ` <jwvvcb47bs0.fsf-monnier+emacs__21035.4545656175$1357869514$gmane$org@gnu.org>
2011-11-24 12:12     ` 24.0.91; package.el (org): Macros in tar packages & order of byte compilation Jambunathan K
2002-01-01  0:33       ` bug#10125: " Jambunathan K
2011-11-24 13:05       ` Eli Zaretskii [this message]
2011-11-24 17:22         ` Jambunathan K
2011-11-24 19:09           ` Glenn Morris
     [not found]           ` <v062i9tk0d.fsf@fencepost.gnu.org>
2011-11-24 19:53             ` Glenn Morris
2011-11-24 22:55             ` Stelian Iancu
2011-11-24 23:54               ` Glenn Morris
2011-11-25  3:31               ` Jambunathan K
2011-11-25 12:32                 ` Stelian Iancu
     [not found]                 ` <CAKvLAojUzYmrUF_64WXEbj9zmBjzZ4gn5cDYVqLTcik41PFJ7w@mail.gmail.com>
2011-11-25 12:58                   ` Jambunathan K
2011-11-25  8:10             ` Eli Zaretskii
     [not found]             ` <hffwhdqov3.fsf@fencepost.gnu.org>
2011-11-25 12:15               ` Jambunathan K
2011-11-25 14:07               ` Chong Yidong
     [not found]               ` <87r50w47o3.fsf@gnu.org>
2011-11-25 14:57                 ` Stefan Monnier
2011-11-25 19:15                   ` Glenn Morris
2011-11-25 19:21                     ` Glenn Morris
2011-11-25 18:19                 ` Glenn Morris
2011-11-25 19:01                   ` Glenn Morris
     [not found]             ` <83vcq88vwt.fsf@gnu.org>
2011-11-25 18:20               ` Glenn Morris
2013-01-11 16:06       ` bug#10125: RFE: require and load-path-shadowing Achim Gratz
     [not found]         ` <jwvvcb34qjg.fsf-monnier+emacs@gnu.org>
2013-01-11 16:56         ` Stefan Monnier
2013-01-11 19:53       ` Achim Gratz
2013-01-11 22:52         ` Stefan Monnier
     [not found]         ` <jwvlibz2v6e.fsf-monnier+emacs@gnu.org>
2013-01-12  8:15           ` Eli Zaretskii
2013-01-12 10:15       ` Achim Gratz
2013-01-12 13:34         ` Bastien
2013-01-12 14:03           ` Stefan Monnier
2013-01-12 14:23             ` Bastien
     [not found]             ` <87liby7a57.fsf@bzg.ath.cx>
2013-01-12 16:12               ` Stefan Monnier
2013-01-12 17:34                 ` Bastien
2013-01-12 10:20       ` Achim Gratz
2013-01-12 12:07         ` Eli Zaretskii
2013-01-12 13:28           ` Stefan Monnier
     [not found]           ` <jwvehhqy1k8.fsf-monnier+emacs@gnu.org>
2013-01-12 13:55             ` Eli Zaretskii
     [not found]             ` <83wqvisdxx.fsf__30242.1131091707$1357998993$gmane$org@gnu.org>
     [not found]               ` <87ip72fi8f.fsf@Rainer.invalid>
2013-01-12 18:39                 ` Eli Zaretskii
2013-01-12 18:42             ` Glenn Morris
     [not found]             ` <71vcb22qgz.fsf__38024.2966501557$1358016217$gmane$org@fencepost.gnu.org>
     [not found]               ` <87hamlbk3w.fsf__41794.7558024482$1358063310$gmane$org@Rainer.invalid>
     [not found]                 ` <87hamis0js.fsf@Rainer.invalid>
2013-01-16  9:45                   ` Kevin Rodgers
     [not found]                   ` <kd5spq$1hh$1@ger.gmane.org>
2013-01-16 10:06                     ` Andreas Schwab
     [not found]                     ` <mvmtxqh5tn0.fsf@hawking.suse.de>
2013-01-16 14:59                       ` Kevin Rodgers
2013-01-12 16:29       ` Achim Gratz
2013-01-12 17:01       ` Achim Gratz
2013-01-13  7:46       ` Achim Gratz
2013-01-13  7:52       ` Achim Gratz
2013-01-15 19:34       ` Achim Gratz
2013-01-11  2:45     ` Jambunathan K

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1RTYzR-00039k-Q6@fencepost.gnu.org \
    --to=eliz@gnu.org \
    --cc=10125@debbugs.gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=kjambunathan@gmail.com \
    --cc=stelian.iancu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).