Re: Refactoring elisp compilation

[Jack Kelly]

Overall, I think the correct action is to set aside this silent-rules
wild-goose-chase.

On Mon, Jul 23, 2012 at 7:26 PM, Stefano Lattarini
<address@hidden> wrote:
> 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.

I don't think so. before-init-hook looked promising, but you can't add
to that hook until after command-line options are parsed and dealt
with (too late). "The only way to change it with real effect is before
dumping Emacs." (
http://www.gnu.org/software/emacs/manual/html_node/elisp/Init-File.html
). Dumping an updated emacs into $builddir seemed promising, but
calling (dump-emacs "newmacs" "/usr/bin/emacs") is just causing
segfaults on my machine.

> 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".

I think the way to do this would be as an improvement to make batch
mode more palatable in general. I think an environment variable or a
change to default behaviour is the least-potentially-breaking
solution.

>> 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.

This sounds sensible, apart from an apparent discrepancy: you've
called one variable $(EMACSFLAGS) and the other $(AM_ELCFLAGS).
Shouldn't they be either $(ELCFLAGS) and $(AM_ELCFLAGS) or
$(EMACSFLAGS) and $(AM_EMACSFLAGS)?

When testing, I think it needs to be tested with emacs and xemacs, and
using something like autoconf (which has some .el files).

-- Jack