Steve Youngs wrote:
VB> 1) the package would be ready to run even without the .elc
True for most packages, but not all. And don't forget about the
'auto-autoloads.el[c]' and 'custom-load.el[c]' that get created
when I build the packages.
Er, what *is* auto-autoloads? Sounds worryingly
meta-level... :-)
VB> 2) the size of the .elc files amounts to something over
VB> 50% size of the .el files (in the case of prog-modes, it's
VB> over 1MB)
It's a trade off. Between size of package and ease of
installation.
VB> 3) these files can be created by anybody who has xemacs,
VB> i.e. anybody who could conceivably want to use them
Very true. Not everyone would want to though (some may not even
know how). There could be problems with requires and macros and
...
Byte-compiling the packages is one way that I can check that
they don't have compile-time errors.
I absolutely don't object to you
compiling packages - just
to the distributing of the compiled files, iff they can be
automatically compiled on end-users machines... Wouldn't local
compilation further increase the software quality (i.e. catching
corruption in CVS - I admit the increase probably wouldn't be very
dramatic)? Can you estimate the percentage of packages (or rather
package code) whose compilation is straightforward?
You can of course build the packages yourself (plenty of people
do). Just grab the "packages" module out of CVS.
What I want is to
minimize downloads (the rest of the world may
have moved on, but I still pay for my phone connection by
the minute)... Say I want the latest version of prog-modes;
how do I get it (and nothing else) from xemacs CVS?
Bye
Vasek