Re: Refactoring elisp compilation

[Stefano Lattarini]

On 07/14/2012 02:18 PM, Jack Kelly wrote:
> Hi automakers,
>
Hi Jack, thank you very much for the patch.

> I had a crack at refactoring the elisp compilation, getting rid of
> elisp-comp and compiling files via a suffix rule. Patch is attached.
> 
> I am not submitting this for inclusion yet,
>
Still, because your patch seems promising (and keep passing the testsuite
both using serial and parallel make in the relevant test cases), I have
amended it for style issues (i.e., quoting 'like this' rather than
`like this', using a more standard format in the commit message, and other
trivialities), reformulated and extended the commit message a bit, and
pushed it to the new, rewindable (i.e., that can be amended and rewritten)
branch 'experimental/elisp-work'; this should help us to experiment more
freely.  I've also added some improved testsuite coverage and several
follow-up patches there.

I will soon post the patch series in this thread, for reference and to
elicit reviews.

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

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

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

> 4. Instead of invoking emacs for all files at once, a new emacs is now
> started for each .el file. This might make incremental builds faster,
> one-time builds slower, both or neither.
>
It might certainly play nicer with "make -jN" (which I'm using more and
more on today's multi-core machines).

> Does anyone know of projects with a significant amount of elisp that
> I could test on?
>
Again I don't; sorry :-(

> Comments extremely welcome.
> 
> -- Jack

Thanks,
  Stefano