[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Can w3-el be precompiled?



>>>>> On 27 May 1998 01:22:25 -0400, gsstark@mit.edu (Gregory S. Stark) said:

 Gregory> Ben Pfaff <pfaffben@pilot.msu.edu> writes:

 >> The version of w3-el that will go into frozen will be the current
 >> one that compiles itself on installation.  However, since w3-el is
 >> only useful for emacs20--not for emacs19 or xemacs19 or
 >> xemacs20--would anyone terribly mind if I changed the unstable
 >> version back to a precompiled version?  (The current
 >> emacsen-common conventions don't allow this AFAICT, perhaps they
 >> should be amended.)

 Gregory> why on earth is it not useful for Emacs v19 or XEmacs ?

Because the version of w3-el that is being shipped requires mule
support (don't ask me why) so xemacs19 and emacs19 are right out.

 Gregory> and the fact that some version of w3 is shipped with XEmacs
 Gregory> doesn't mean it wouldn't be useful to install a more
 Gregory> up-to-date version.

Because it breaks the xemacs20 version of w3 when installed.  If the
w3-el person would like to figure out why it breaks xemacs20 (w3) I'd
have no problem with it being installed, but IMO it's a waste of time
to figure out why since xemacs20 already contains a functioning
version of w3.

 Gregory> I agree compiling w3 takes far too long to put in the
 Gregory> postinst of a package.  I don't actually see the problem
 Gregory> with building binary packages that install .elc files
 Gregory> directly into the directories they end up, but I would
 Gregory> expect there to be packages for each of the emacsen. Though
 Gregory> it might take other people to help build for the various
 Gregory> "architectures".

No, this is a bad idea which is why the emacsen policy exists. (and no 
I won't rehash why it's a bad idea.  go back and read the thread about 
it)

Dres (XEmacs maintainer)
-- 
@James LewisMoss <dres@dimensional.com> |  Blessed Be!
@    http://www.dimensional.com/~dres   |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: