From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: Org Build System (aka Makefile)
Date: Mon, 13 Aug 2012 08:11:45 +0200 [thread overview]
Message-ID: <874no7qq1q.fsf@Rainer.invalid> (raw)
In-Reply-To: 87r4rb690j.fsf@gnu.org
Bastien writes:
> One thing I need to understand: what are the warnings that you have
> when compiling within a single process and you don't when compiling
> with one process per file?
Emacs Lisp as a dynamic language has no concept of a "well-formed"
program that can be verified by just looking at the source. Correctness
of the program depends on entirely on the context, specifically any
bindings that have been made. Now, for the same reason it also doesn't
really have a concept of "compilation" like other languages that need to
be translated. Running the byte-compiler will not only byte-compile,
but also alter the context (predominantly via special forms that are
evaluated at compile-time; but in other ways, too). So, running it with
one process per file provides the most minimal context, but not
necessarily the "best" or "correct" one. I could just as well pre-load
org-install into the context of each compilation and things would look
different again.
The warnings you get from the byte-compiler are just noting when the
expected context and the encountered one differs (like the bytecompiler
seeing a function `foo´ being invoked, but doesn't know that is
defined). This may or may not be an error at runtime, depending on what
the context looks like then.
> The next thing I'd like to know is _why_ -- but even a rough answer
> to the first question would help me take a decision about this.
There is no right or wrong answer to this, there are literally an
infinite number of ways to deal with that problem. But it all comes
down to managing dependencies and ensuring proper setup of the context,
both at compile-time and run-time. Org currently takes the heavy-handed
approach of (mostly) requiring all dependencies at compile-time, except
when that would create recursive requires. This drags in a lot of
mostly useless context into each compilation and can even hide some
problems when some of the context is only indirectly required. It also
subverts the goals of dynamic (auto-)loading at run-time, since instead
of just pulling in the functions needed it will pull in rather large
bodies of code.
I'd be in favor of automatic dependency management in the autoloads
style, but that would be a larger undertaking for a later time.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
next prev parent reply other threads:[~2012-08-13 6:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-15 20:37 Org Build System (aka Makefile) Achim Gratz
2012-07-15 21:38 ` Bastien
2012-08-09 17:03 ` Achim Gratz
2012-08-10 7:17 ` Bastien
2012-08-12 13:56 ` Achim Gratz
2012-08-12 18:56 ` Eric Schulte
2012-08-12 20:41 ` Achim Gratz
2012-08-13 13:16 ` Eric Schulte
2012-08-13 13:45 ` Bastien
2012-08-13 19:27 ` Achim Gratz
2012-08-13 22:43 ` Eric Schulte
2012-08-14 6:13 ` Achim Gratz
2012-08-14 12:46 ` Eric Schulte
2012-08-14 22:06 ` Bastien
2012-08-15 16:35 ` Achim Gratz
2012-08-14 22:45 ` Bastien
2012-08-15 17:55 ` Achim Gratz
2012-08-15 18:56 ` Bastien
2012-08-13 19:47 ` Achim Gratz
2012-08-14 22:07 ` Bastien
2012-08-12 22:27 ` Bastien
2012-08-13 6:11 ` Achim Gratz [this message]
2012-08-13 7:40 ` Bastien
2012-08-13 11:42 ` Achim Gratz
2012-08-13 13:13 ` Bastien
2012-08-13 14:17 ` Achim Gratz
2012-08-13 14:48 ` Bastien
2012-08-13 18:56 ` Achim Gratz
2012-08-13 5:34 ` Bastien
2012-08-12 16:58 ` Samuel Wales
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=874no7qq1q.fsf@Rainer.invalid \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/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).