Jambunathan K <kjambunat...@gmail.com> writes: > Filed as an umbrella bug - > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125.
I believe both the reason and the cure you suggest there are not entirely correct, even though it might be generally nice to be able to specifiy the order of things. I have been having no issues when compiling org-mode using the same method that package-manager uses (that is in a single process and in alphabetical order). There are some requisites for doing that correctly, which I might not have fully comprehended: 1) there must not be any stale .elc files around since Emacs would prefer these over the newer .el files and get lost. Similarly, 2) the source directory must be first in loadpath, otherwise Emacs might pick up pre-existing sources (or compiled files) that are packaged with Emacs. Lastly, 3) at least for macros, Emacs must not have a different definition in-core already before the compile starts because then it will never look for the newer definiton in the source file (or too late). I keep 1) fulfilled in the makefile by nuking all .elc files before starting the compile, 2) by specifying the loadpath directly at the command line and 3) by specifying -Q to the Emacs process that does the compilation. So far I haven't found any ill effects of doing that, but please feel free to check out my Makefile fork. I'll have to check if I already used that method to compile the latest version of org-mode I use at work since that one gets much more use... I don't know how the last condition can be fulfilled in package manager without starting a new Emacs process, but perhaps it is possible. Before settling on this make process I have been unsuccessfully trying to automatically unravel the interdependencies between org-mode source files. Aside from not having found any tools that deliver dependencies in a way that would be useful for make, it also can not really work since there are some circular dependencies in the sources. HTH, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
