Re: Refactoring elisp compilation

[Stefano Lattarini]

On 07/15/2012 01:17 AM, Jack Kelly wrote:
>
>>> I want to generate some discussion first. I have the following
>>> concerns:
>>>
>>> 1. I would like to add silent-rules support,
>>
>> Me too, but since the lack of it wouldn't be a regression, that issue
>> can be tackled later.
>>
>>> but it's not completely
>>> straightforward. The call to file_contents is buried within
>>> &am_install_var. I'm thinking of adding another option to
>>> am_install_var that adds a silent var to the file_contents call.
>>> Something like am_install_var( '-silent_var=FOO', ...), which would
>>> result in a call to define_verbose_tagvar('FOO') and AM_V_FOO =>
>>> verbose_flag('FOO') in the file_contents call.
>>>
>> Now that the automake from master enables support for silent rules
>> unconditionally, we might bypass preprocessing by automake and
>> encode something like this directly in lisp.am (untested!):
>>
>>   AM_V_ELISPCOMP = $(address@hidden@)
>>   AM_V_ELISPCOMP_ = $(address@hidden@)
>>   AM_V_ELISPCOMP_0 = @echo ECOMP $@;
>>
>>   .elc.el:
>>         $(AM_V_ELISPCOMP) ...
>>
>> We'll see.
> 
> I can see that working, but do you think it's smart to have
> silent-rules machinery outside of automake.in? It seems to break
> consistency.
>
See below for how all of this might be made moot.

> I'd also call the silent var `ELCOMP', as EL is used for
> elisp everywhere.
>
Agreed.

>>> 2. If I implement (1) above, it's still not straightforward. The rules
>>> will be invoked even if $(EMACS) = "no", so the suffix rule guards
>>> against that, becoming a no-op if $(EMACS) = no. That will be
>>> rechecked by on every invocation of "make", for every file in
>>> $(ELCFILES).
>>>
>> I don't see how or where this would be a problem ...  Am I missing
>> something?
> 
> It makes deciding where to place the $(AM_V_ELISPCOMP) more awkward
> because you don't want to spew ELCOMP messages on no-ops.
>
Ah, OK.  But that won't be a problem if we drop my previous attempt and
simply make proper use of $(AM_V_P) in the '.el.elc' recipe (that variable
has just been introduced in Automake 1.12.2, and is meant to be used as a
shell conditional in recipes to determine whether the build is silent or
not).  This way, no new Automake conditional will be needed.

Unfortunately, all this speaking about silent rules is moot until we manage
to stop emacs spewing out messages about startup files being loaded; for
example, on my debian system:

Loading 00debian-vars...
Loading 42hyperlatex...
Loading /etc/emacs/site-start.d/50a2ps.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50bashdb.el (source)...
Loading /etc/emacs/site-start.d/50cmake.el (source)...
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
Loading /etc/emacs/site-start.d/50erlang-mode.el (source)...
Loading /etc/emacs/site-start.d/50festival.el (source)...
Loading /etc/emacs/site-start.d/50ftnchek.el (source)...
Loading /etc/emacs/site-start.d/50gforth.el (source)...
Loading /etc/emacs/site-start.d/50global.el (source)...
Loading /etc/emacs/site-start.d/50gnu-smalltalk-el.el (source)...
Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)...
Loading /etc/emacs/site-start.d/50libperl-critic-perl.el (source)...
Loading /etc/emacs/site-start.d/50lilypond-data.el (source)...
Loading /etc/emacs/site-start.d/50maxima-emacs.el (source)...
Loading /etc/emacs/site-start.d/50psvn.el (source)...
Loading /etc/emacs/site-start.d/50pylint.el (source)...
Loading pylint...
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...

> I've decided
> that I now prefer using an AM_CONDITIONAL for this reason. Perhaps
> AM__HAVE_EMACS, if that fits the style?
>
Given my comments above, let's wait before venturing there, OK?

>>> Perhaps an AM_CONDITIONAL in AM_PATH_LISPDIR is the way
>>> to fix this? Existing tests shoudn't break because they set EMACS=no
>>> either at configure time or in configure.ac.
>>>
>>
>>> 3. On my Ubuntu system at least (and probably debian systems as well),
>>> each call to emacs puts out a few messages of the form "Loading
>>> 00debian-vars...". This isn't too bad, just unsightly. Any shell/elisp
>>> wizards have a suggestion?
>>>
>> I'm no elisp wizard (nor magician, conjurer, or juggler :-), so I'm
>> not able to help here, sorry.  Maybe we could instruct emacs not to
>> load the system-wide startup file at all?
> 
> Possible, but I don't think it's smart. If the site-files do any sort
> of load-path work to make finding things possible, then I think it
> could cause breakage when the file being compiled fails to find some
> already-installed macro package.
>
At least we should find a way to silence all messages that are not
real warnings or errors...  Otherwise, adding silent rules support
would just be pointless.

Thanks,
  Stefano