Re: Refactoring elisp compilation

[Stefano Lattarini]

On 07/23/2012 01:26 PM, Jack Kelly wrote:
> Overall, I think the correct action is to set aside this silent-rules
> wild-goose-chase.
>
Glad we agree.  And there's no need to hurry anyway, since Automake 1.13
is not going to be release soon (it will take at least two more months,
even in the most optimistic estimates).

> [SNIP]

> Stefano Lattarini wrote:
>>
>> 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.
>
Good.  Do you fancy bringing this up on the Emacs list?  As I said, no
need to hurry.

>>> 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).
>
Oops, I meant $(AM_EMACSFLAGS).  Sorry for the confusion.

> Shouldn't they be either $(ELCFLAGS) and $(AM_ELCFLAGS) or
> $(EMACSFLAGS) and $(AM_EMACSFLAGS)?
>
Absolutely!

> When testing, I think it needs to be tested with emacs and xemacs, and
> using something like autoconf (which has some .el files).
>
I can do this.  If you can find an autoconfiscated package that makes a
deeper and more complex use of Emacs lisp than Autoconf does, and test
with that, it would be great.

Thanks,
  Stefano