From xemacs-m  Tue Apr 22 15:57:53 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id PAA18171
	for <xemacs-beta@xemacs.org>; Tue, 22 Apr 1997 15:57:52 -0500 (CDT)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.5/8.8.5) id OAA02904;
	Tue, 22 Apr 1997 14:11:06 -0700
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: Anatomy of xemacs.tar.gz (was Re: Patch problem)
References: <m2sp0k5hqq.fsf@bong.saar.de> 	<m2lo6cb2w3.fsf@altair.xemacs.org> <199704221216.OAA16669@atusel63.alcatel.at>
X-Url: http://www.miranova.com/%7Esteve/
X-Face: #!T9!#9s-3o8)*uHlX{Ug[xW7E7Wr!*L46-OxqMu\xz23v|R9q}lH?cRS{rCNe^'[`^sr5"
 f8*@r4ipO6Jl!:Ccq<xoV[Qz2u8<8-+Vwf2gzJ44lf_/y9OaQ`@#Q65{U4/TC)i2`~/M&QI$X>p:9I
 OSS'2{-)-4wBnVeg0S\O4Al@)uC[pD|+
X-Attribution: sb
From: Steven L Baur <steve@miranova.com>
In-Reply-To: Martin Pottendorfer's message of Tue, 22 Apr 1997 14:16:28 +0200
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Date: 22 Apr 1997 14:11:04 -0700
Message-ID: <m2vi5eu5jr.fsf_-_@altair.xemacs.org>
Lines: 68
X-Mailer: Gnus v5.4.46/XEmacs 20.2(beta2)

Martin Pottendorfer <Martin.Pottendorfer@aut.alcatel.at> writes:

> IMHO all files which are generated should really be generated when
> doing `make all-elc'; therefore it's no need to distribute patches
> of `lisp/prim/autoloads.el'.

I guess since one of the major unwritten rules of XEmacs tarballs has
been broken with the 19.15-p2 release this is a good time to bring
this up.

The `optional' stuff included in an XEmacs tarball include the Lisp
.elcs, configure, the auto-autoloads.el/custom-load.el files and the
generated info documentation.  Given a complete environment and the
right patches, they are all possible to generate from scratch.

configure is included so that people do not have to have autoconf
installed.  Since the local changes introduced to make `config.status
--recheck' work, I am the only person who can regenerate configure
from scratch.

auto-autoloads.el/custom-load.el are included because until very
recently the process used to generate them was *painful* in the
extreme.  They still should be included as part of the base system
because debugging them when things go wrong is a horrible exercise I
don't wish to force on anyone.

The info tree is mostly a matter of courtesy and tradition.  Currently 
there are texinfo files that must be processed by a MULE XEmacsen.
Otherwise I suppose we could save space in the tarball and not include 
them.  The generation procedure uses the latest Makeinfo (with one
patch previously posted to this list and submitted to the texinfo
maintainers).  Omitting the info tree would save about 2.3MB in the
current tarball.

The .elcs are included as a matter of tradition.  Traditionally it was 
very dicey to build XEmacs without any bytecompiled lisp and without a 
preexisting binary.  This hasn't been true for months.  For weekend
betas and some weekday betas, I build the distribution starting
without .elcs and haven't experienced any failures.  There are three
reasons I resist not including them:

1.  If anything goes wrong in bytecompiling them, I am the only one
    who sees it.  Things going wrong mostly means having out of date
    emacs lisp somewhere.  I build from clean directories with no
    site-lisp directories involved.

2.  Although a reliable procedure, bytecompiling the entire lisp tree
    is a time consuming one.  On an otherwise-idle Pentium 200 it
    takes about 55 minutes to complete (with an XEmacs v20 specially
    compiled for speed).

3.  The source tarball is *huge*.  The intrepid person who goes to all 
    the effort download something that big should be rewarded.  In
    this case it's an extra 4.6MB in the tarball to save a potentially
    *long* time bytecompiling all the Lisp.  You may spend extra time
    downloading, but you have guaranteed clean bytecompiled lisp,
    and guaranteed clean and complete info documentation.

Splitting the tarball at this time means extra work for me, and extra
work for everyone downloading and installing the extra pieces.
Leaving it as one monolithic tarball means a bit less extra work for
me, but reducing installation to the fundamental unzip/tar/configure/make.

In short, I think the way XEmacs tarballs have been distributed is the 
Right Way to do it under the current conditions.
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be billed at $250/message.

