On Sun, Jul 15, 2012 at 7:33 AM, Stefano Lattarini
<stefano.lattar...@gmail.com> wrote:
> On 07/14/2012 02:18 PM, Jack Kelly wrote:
>> 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.
Ah, thank you. I am now tracking that branch and will base further
patches off it.
> I will soon post the patch series in this thread, for reference and to
> elicit reviews.
Most of it looked OK, except for that nit I've already posted about.
>> 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 = $(AM_V_ELISPCOMP_@AM_V@)
> AM_V_ELISPCOMP_ = $(AM_V_ELISPCOMP_@AM_DEFAULT_V@)
> 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. I'd also call the silent var `ELCOMP', as EL is used for
elisp everywhere.
>> 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. I've decided
that I now prefer using an AM_CONDITIONAL for this reason. Perhaps
AM__HAVE_EMACS, if that fits the style?
>> 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.
>> 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 :-(
I've seen a little elisp in autoconf, so once we've got this hammered
out I'll do some testing there.
-- Jack
