Let's summarize. It is no a matter of "exposing the user to the warnings" or not.
It is a matter of exposing the user to the warnings that might be useful to him -- i.e. the ones he might want to report to the list just to let the developers know, or in the context of a bug hunt. The warnings you get by compiling Elisp files within a single Emacs process are *not* useful to the users because these warnings happen during context-free compilation, and as such, they are not relevant to what the user evaluates when he loads Org (even worse: those warnings may lead him to misinterpret what is missing at run time, whereas they warn about things that are missing at comile time.) So let's stick to the current default `make' for compilation. However, I would suggest these changes to the current default.mk: - Have a target `make single' (useful for developers) - `make test' should use the default make compilation (within one Emacs process), because this target is primarily for performing tests, not for checking warnings. - `make test single' should run the tests *and* compile each file in a separate Emacs process -- so that it gives as much info as the developers may desire. - `make elint' would run the current `make _COMPILE_=slint3'. - `make elint single' would run the current `make _COMPILE_=slint4' (even though I would not complain if we get rid of this target.) - Let's get rid of the _COMPILE_ variable: it is not handy to have to edit this just for running checks. I hope our brains now all compile fine within the same context. :) Achim, if you are okay with the suggestions above, can you make the relevant changes? Thanks! -- Bastien
