Re: Org Build System (aka Makefile)

[Achim Gratz <Stromeko@nexgo.de>]

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