[csw-maintainers] cswclassutils

[Ben Walton]

Excerpts from Peter FELECAN's message of Thu Jul 16 12:44:58 -0400 2009:
> 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

Sure, it can be patched around, but that leaves the work to each
maintainer.

> that. BTW, can you provide an example of a project didn't providing the
> direct or indirect elc target?

Ruby is the example currently in my mind.  The misc/ directory
contains the ruby mode files, but nothing else.  As far as I can tell,
there is no make target to even get those files installed.  I don't
have an example where the .el files get installed but not
byte-compiled, so this leaves the maintainer doing work in either
case.

> Quick example for abbrev:
> 
> .el  13226
> .elc 11695

These line up roughly with what I've seen:
14452  inf-ruby.el
10008  inf-ruby.elc
 6747  ruby-electric.el
 6290  ruby-electric.elc
38653  ruby-mode.el
29260  ruby-mode.elc
 1746  ruby-style.el
 1983  ruby-style.elc
 4481  rubydb2x.el
 3952  rubydb2x.elc
 4613  rubydb3x.el
 4177  rubydb3x.elc

...so it's not huge (somewhere south of 50%), but it is something.  If
space were the ultimate goal, shipping .elc primarily and .el as a
source package would be better.  It was only part of my goal though.
Personally, I prefer the ship one, get both approach, but as I said,
I'll go with the preferred decision here.

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

This works, as I said, it's just not my preference.

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

I don't think this is 'strictly' true.  It seems the preferred files
(for packages I looked at) were the .el ones.  There is then some
'fancy framework' for building/installing these for multiple flavours
of emacs, which can live together peacefully.  The debian policy[1]
doesn't seem to explicitly state which files are to be shipped
though.

Two packages I looked at quickly (from Ubuntu, not Debian, but...)
were css-mode and sepia.  In each case, they placed .el files in
/usr/share/emacs/site-lisp/ and then used a hook script in
/usr/lib/emacsen-common/packages/install/ to do byte compilation.

Thanks
-Ben

[1] http://www.debian.org/doc/packaging-manuals/debian-emacs-policy
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20090716/9f74d3ba/attachment-0002.asc>