Re: Refactoring elisp compilation

[Stefano Lattarini]

On 07/23/2012 10:29 AM, Jack Kelly wrote:
> On Tue, Jul 17, 2012 at 7:04 PM, Stefano Lattarini
> <address@hidden> wrote:
>> Maybe we could try to write to the Emacs list for help at this point...
> 
> I wrote the emacs list, and they pointed me to the NOMESSAGE argument
> for (load). Unfortunately the rabbit hole goes deeper...
> 
> Emacs defines a variable, site-run-file, that is meant to be the
> "first" thing loaded, before .emacs and before default.el. We can get
> at that, but not with -Q. An autoconf check seems the correct approach
> here (as part of AM_PATH_LISPDIR), running something like:
> 
> $(EMACS) -batch --eval "(princ site-run-file)" 2>/dev/null
>
OK, so far sounds simple and sensible.

> (Is the redirect to /dev/null safe for DJGPP and/or MSYS?)
>
For MSYS, yes.  For DJGPP, I think so (/dev/null redirections are used
throughout the Automake codebase, and nobody has ever complained about
them), bot honestly I don't deeply care: DJGPP should be considered
obsolete anyway.

> Because debian has to do things their own way, (I'm sure they have
> their reasons), the initialisation process on debian systems is a
> little more complicated than just running the site-run-file:
> http://stackoverflow.com/q/189291/429232
>
Ouch.

>
> Therefore, we can check if it's a debianised emacs with something like:
> 
> $(EMACS) -batch --eval "(unless (boundp 'debian-emacs-flavor) (kill-emacs 1))"
> 
> And we can get the actual flavour with this:
> 
> $(EMACS) -batch -eval "(princ debian-emacs-flavor)" 2>/dev/null
> 
> It is fairly easy to advise (load) so that it's always loading silently:
> 
> (defadvice 'load ('before 'silently) (ad-set-arg 2 t))
> (ad-activate 'load)
> 
> Then the next step is to emulate the normal startup, which would be
> something like:
> 
> (let ((debian-emacs-flavor (quote $flavor)) (site-run-file \"$sitefile\"))
>   (when (debian-emacs-flavor)
>     (load \"debian-startup\")
>     (debian-startup debian-emacs-flavor))
>   (load site-run-file))
>

Yikes :-(

I strongly fear this poking in Debian internals is too fragile w.r.t.
forward compatibility.  I'd rather avoid further debacles like the
install-info one:

  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213524>
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9773>

> At this point, we're well beyond what's sensible for a makefile
> snippet, so we should really move it all into a .el file that lives in
> $auxdir or a shell script with the elisp embedded. Do you have a
> preference? I suppose a .el file saves an extra fork per .el file,
>
My preference thus go to a '.el' file that lives in $auxdir.  But first
I'd have to be convinced that catering to the Debian setup is actually
a good move.  That won't be easy ;-)

OK, let's take a step back.

Are we sure that Emacs doesn't offer any way to pass "early" code fragments
to be eval'd before anything else not in the Emacs core is read or executed?
That would be great, and allow us to implement a much simpler and more
portable workaround.

Even better: maybe Emacs offers an environment variable that could be used
to control the verbosity of (load), and maybe of other functions as well?
Something akin to PYTHONVERBOSE for python:
<http://docs.python.org/release/3.1.5/using/cmdline.html#envvar-PYTHONVERBOSE>

If this is not the case, could such a variable be added to future Emacs
version?  This way, our elisp byte-compile rules would be kept simple,
with only the (IMHO minor) annoyance that silent rules wouldn't work very
well for them with "non recent" emacs versions.  And this annoyance would
be automatically mitigated as the times goes by and non-very-recent Emacs
versions become first "older", then "old", and finally "ancient".

> and
> I think there's sufficient command-line handling built into emacs that
> it shouldn't be too hard to write a compile.el or el-compile.el (do
> you have a name to suggest?).
> 
> -- Jack

Finally, an update on the status of the 'elisp-work' branch: I plan to
add support for '$(EMACSFLAGS)' and '$(AM_ELCFLAGS)' being automatically
passed to our emacs invocations, add a couple of new test cases, and
then merge the branch into 'master'.  Since the lack of 'silent-rules'
support is not a regression, I don't want that to block the integration
of all the improvements done so far.

Regards,
  Stefano