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.
signature.asc
Description: PGP signature
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
