Hi,
Ben == Ben Pfaff [EMAIL PROTECTED] writes:
Ben This morning I uploaded a version of w3-el that doesn't compile upon
Ben installation--instead, there are separate precompiled packages for
Ben Emacs 19 and Emacs 20, plus a shared documentation package. I see
Ben this as a better way to go
[EMAIL PROTECTED] (Ben Pfaff) writes:
This morning I uploaded a version of w3-el that doesn't compile upon
installation--instead, there are separate precompiled packages for
Emacs 19 and Emacs 20, plus a shared documentation package. I see
this as a better way to go than forcing the
Jim Pick [EMAIL PROTECTED] writes:
I agree that waiting for the large add-on packages to compile during
installation is very aggravating. At the same time, it puts a lot of
load on the maintainers to build so many byte-compiled versions.
I'm not sure what you mean by this. With w3-el,
[EMAIL PROTECTED] (Ben Pfaff) writes:
I am trying to remember the rationale we had for making Emacs' addon
packages compile when they install themselves, and I can't remember
it. Perhaps you can remind me.
The main reasons I recall were that we didn't want to have 4 (or more
later) different
Quoting Ben Pfaff ([EMAIL PROTECTED]):
I'm not sure what you mean by this. With w3-el, I just set it up to
build each flavor in a separate subdirectory; i.e.,
mkdir e19; cd e19; ../configure --with-emacs=emacs19; make
mkdir e20; cd e20; ../configure --with-emacs=emacs20; make
Michael Stone wrote:
Simple because you didn't have to worry about xemacs. For other
maintainers, they'd need e19, e20, xe19, and xe20. That would take what,
about 100M? Not so elegant.
*shrug* The lesstif maintainer needs more than that just to compile
his package :-)
Supporting only a
6 matches
Mail list logo
