From xemacs-m  Fri Dec 13 15:39:52 1996
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id PAA09635 for <xemacs-beta@xemacs.org>; Fri, 13 Dec 1996 15:39:52 -0600 (CST)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA09469; Fri, 13 Dec 1996 13:38:48 -0800
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id NAA00977; Fri, 13 Dec 1996 13:38:44 -0800
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA13626; Fri, 13 Dec 1996 13:38:42 -0800
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id NAA00529; Fri, 13 Dec 1996 13:38:41 -0800
Date: Fri, 13 Dec 1996 13:38:41 -0800
Message-Id: <199612132138.NAA00529@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: georgn@canada.Sun.COM
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@xemacs.org
Subject: Re: Distribution idea
In-Reply-To: <199612122213.RAA09926@detlev.canada.sun.com>
References: <199612111850.NAA03282@nvwls.cc.purdue.edu>
	<199612122042.MAA28489@xemacs.eng.sun.com>
	<m2k9qntqjd.fsf@altair.xemacs.org>
	<199612122213.RAA09926@detlev.canada.sun.com>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>
Mime-Version: 1.0 (generated by tm-edit 7.94)
Content-Type: text/plain; charset=US-ASCII

>>>>> "Georg" == Georg Nikodym <georgn@canada> writes:

>>>>> "sb" == Steven L Baur <steve@miranova.com> writes:
>>>>> "Martin" == Martin Buchholz <mrb@eng.sun.com> writes:

Martin> But in order to avoid creating a dependency on having gzip on
Martin> the PATH, we need to do the gunzipping within code that is
Martin> linked in to XEmacs.  This means that zlib would have to
Martin> become a standard part of XEmacs. This would make XEmacs a
Martin> little bigger (my libz.a is 67k). Who wants to implement it?

sb> No.  You have to have gzip/gunzip to do anything meaningful with
sb> the distribution tarfile (tar zxf still requires a gzip binary),
sb> so I don't think a Makefile dependency on them is too much of a
sb> hardship.

Georg> Well, funny you should mention this.

Georg> There is a tension between having stuff built into XEmacs and having
Georg> co-processes.  Building stuff into XEmacs makes it bigger.  Bigger
Georg> means fork(2)/exec(2) for co-processes take longer.  However building
Georg> things in adds to the already untenably large management load borne
Georg> largely by the maintainers.  However, fork(2)/exec(2) pairs from large
Georg> processes like XEmacs already take too long, so the customers want
Georg> integration...

Georg> This turns into the same kind of thing as government deficit
Georg> financing.  Pay now or pay later.

Georg> Of course, since deficits aren't eliminated overnight, and we won't
Georg> easily reddress the code bloat we work with daily, might I suggest
Georg> that the zlib stuff be made into a shared object that XEmacs can
Georg> dynamically link on demand...  I suspect that you'll find that this is
Georg> a little faster than fork/exec.

When I said ``linked in to XEmacs'', I leave open the possibility of
dynamic linking.  This is certainly doable, as the example of Perl has
proven.  But it's not currently working in XEmacs yet, and would
require a considerable amount of configure hacking.  Does autoconf 2
know about dyanmic linking?  I think not.  

I am not convinced that there is enough of a win to use dynamic
linking for the gzip integration:  
- Whether we use dynamic linking or not, we will pay the price of the
  added disk space.
- There will be no sharing between different (i.e. non-XEmacs)
  executable files, since XEmacs will have to come with its own.
- A well designed OS will allow sharing of text between processes
  running the same executable.

Martin

