[csw-maintainers] cswclassutils

[Peter FELECAN]

Philip Brown <phil at bolthole.com> writes:

> On Thu, Jul 16, 2009 at 12:21:15PM -0400, Ben Walton wrote:
>> Excerpts from Peter FELECAN's message of Thu Jul 16 11:51:57 -0400 2009:
>> 
>> > Reducing the payload is not, in my opinion, a sufficient reason.
>> 
>> I thought that payload reduction in addition to a standard method for
>> packaging was a good enough win.

I'm not opposed to having this class script for projects don't providing
make targets for .elc generation --- even if it's easy to patch for
that. BTW, can you provide an example of a project didn't providing the
direct or indirect elc target?

> It should be mentioned that it can be a significant "payload reduction".
> or.. erm.. it was in the case of python. Ben, why dont you give a specific
> example of just how much space is saved?

Quick example for abbrev:

.el  13226
.elc 11695

Note, however that I provide the .el files in compressed form

> Or, contrariwise, we may indeed want to only distribute the compiled
> stuff and have separate src packages, as you say.

This is how it's done for my packages containing emacs lisp code.

>> I prefer to have the .el version around for reading, but that's partly
>> due to me being a relatively new emacs user and wanting to see how
>> things are done.

This is why the .el are available in a separate, "source" package.

> dont forget to mention/compare how debian and other distros do it.
> not that we HAVE to do it the same way, but it's nice to have the
> reference.

Debian, and all the other distros that I know are doing it by providing
.elc in the main package and .el in a separate, optional package. What
they are doing in addition is implement a mechanism of recompiling
site-lisp packages on a package by package basis --- they have a emacs.d
directory containing a script by package installing in site-lisp; this
is something that is probably worth the effort to implement.

-- 
Peter