package without .elc files and emacs guidelines

[Patrice Dumas]

Hello,

In the librep there are some .el files, and Michal Jaegermann explained
in 
https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23
that the .elc files are not needed (and sometimes harmful). This is not
very consistent with the Emacs guidelines. Maybe the guidelines could be
amended for this case?

--
Pat

[Jonathan Underwood]

2008/10/17 Patrice Dumas <pertusus(a)free.fr&gt;:
>  Hello,
>
>  In the librep there are some .el files, and Michal Jaegermann explained
>  in
>  https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23
>  that the .elc files are not needed (and sometimes harmful). This is not
>  very consistent with the Emacs guidelines. Maybe the guidelines could be
>  amended for this case? 
I think he's wrong. If something doesn't work when byte compiled
(.elc), then that's a bug. When loading many lisp files at startup,
byte compilation still provides noticeable speedup, even on recent
machines. So, no, I'd oppose changing the guidelines in this regard.
It's a bit like saying "we don't need .pyc" files, as we can work just
from the .py files (except that emacs doesn't do automatic byte
compilation in the way that python does if a pyc isn't present or is
older than the .py).

Michal does allude to one ugliness of byte compilation - you do often
need a packages .el files around when doing byte compilation of
another package for function definitions, and this can lead to
bootstrapping needs (see emacs-vm and emacs-bbdb for an example).

[As an aside, that package should really be putting its files in a
subdirectory of %{emacs_lispdir}.]

[Ville Skyttä]

On Wednesday 22 October 2008, Jonathan Underwood wrote:
>  2008/10/17 Patrice Dumas <pertusus(a)free.fr&gt;:
>  > Hello,
>  >
>  > In the librep there are some .el files, and Michal Jaegermann explained
>  > in
>  > https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23
>  > that the .elc files are not needed (and sometimes harmful). This is not
>  > very consistent with the Emacs guidelines. Maybe the guidelines could be
>  > amended for this case?
>
>  I think he's wrong. If something doesn't work when byte compiled
>  (.elc), then that's a bug. 
Strictly speaking, I don't think it's always quite that black and white.

Depending on the .el, byte compilation in one configuration may end 
up "optimizing away" things that are not needed in that configuration, but 
might be needed in other configurations where the .elc is supposed to be 
used.  Or the other way around, it may end up byte compiling things that are 
needed in the build configuration but are not needed and can cause duplicate 
definitions or other weirdness in others.  For example detecting availability 
of some features - typically .el that supports multiple *Emacs versions by 
providing internal replacements for some things not found in the build 
configuration - and conditionally byte compiling them.

Reviewing eval-when-compile's in the .el might reveal some but not all 
potential problems.  defmacro's are another thing that could be useful to 
check (AFAIU, IIRC, but then again I don't have that deep knowledge about 
these things).

In practice this is rarely a problem in Fedora as the .elc are quite likely to 
be used in pretty much the same configuration (Emacs version, other lisp libs 
loaded from load-path) as with what they were built with.  But if 
configurations differ enough such as .elc byte compiled with Emacs ending up 
in XEmacs' load path or vice versa, or .elc byte compiled with one *Emacs 
version and run with another, breakage is not at all unlikely.  Granted, the 
best fix for these situations is not omitting byte-compilation altogether, 
but rather ensuring incompatible *emacs don't mess around with .elcs in each 
others' load paths, and using strict enough rpm level dependency versioning 
on the target *emacs.

[Jonathan Underwood]

2008/10/23 Ville Skyttä <ville.skytta(a)iki.fi&gt;:
>  On Wednesday 22 October 2008, Jonathan Underwood wrote:
> > 2008/10/17 Patrice Dumas <pertusus(a)free.fr&gt;:
> > > Hello,
> > >
> > > In the librep there are some .el files, and Michal Jaegermann explained
> > > in
> > > https://bugzilla.redhat.com/show_bug.cgi?id=431250#c23
> > > that the .elc files are not needed (and sometimes harmful). This is not
> > > very consistent with the Emacs guidelines. Maybe the guidelines could be
> > > amended for this case?
> >
> > I think he's wrong. If something doesn't work when byte compiled
> > (.elc), then that's a bug.
>
>  Strictly speaking, I don't think it's always quite that black and white.
>
>  Depending on the .el, byte compilation in one configuration may end
>  up "optimizing away" things that are not needed in that configuration, but
>  might be needed in other configurations where the .elc is supposed to be
>  used.  Or the other way around, it may end up byte compiling things that are
>  needed in the build configuration but are not needed and can cause duplicate
>  definitions or other weirdness in others.  For example detecting availability
>  of some features - typically .el that supports multiple *Emacs versions by
>  providing internal replacements for some things not found in the build
>  configuration - and conditionally byte compiling them.
>
>  Reviewing eval-when-compile's in the .el might reveal some but not all
>  potential problems.  defmacro's are another thing that could be useful to
>  check (AFAIU, IIRC, but then again I don't have that deep knowledge about
>  these things).
>
>  In practice this is rarely a problem in Fedora as the .elc are quite likely to
>  be used in pretty much the same configuration (Emacs version, other lisp libs
>  loaded from load-path) as with what they were built with. 
Yes, key here is having the correct BuildRequires to ensure other
elisp packages of relevance are installed at build time (eg. emacs-vm
and emacs-bbdb require each other at build time to ensure the correct
macros are compiled).

 But if
>  configurations differ enough such as .elc byte compiled with Emacs
> ending up
>  in XEmacs' load path or vice versa, or .elc byte compiled with one *Emacs
>  version and run with another, breakage is not at all unlikely.  Granted, the
>  best fix for these situations is not omitting byte-compilation altogether,
>  but rather ensuring incompatible *emacs don't mess around with .elcs in each
>  others' load paths, and using strict enough rpm level dependency versioning
>  on the target *emacs. 
Agreed, but currently we try to mitigate that by having packages
Require the version of Emacs that was used for byte compilation (or a
later version) with the rather messy macros in the guidelines. If we
want to broaden our scope further to allow for multiple emacs versions
to be installed, then we can do what Debian does. But, really, I think
that's an unnecessary world of pain.