From xemacs-m  Mon May 19 01:33:51 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id BAA17526
	for <xemacs-beta@xemacs.org>; Mon, 19 May 1997 01:33:50 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA00352 for <xemacs-beta@xemacs.org>; Sun, 18 May 1997 23:47:59 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id XAA01031; Sun, 18 May 1997 23:33:13 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA10888; Sun, 18 May 1997 23:33:15 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id XAA10386; Sun, 18 May 1997 23:33:11 -0700
Date: Sun, 18 May 1997 23:33:11 -0700
Message-Id: <199705190633.XAA10386@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: xemacs-beta@xemacs.org
Subject: Re: Success w/tweaking, 20.3-b1, linux-2.0.30
In-Reply-To: <m2yb9cm1z4.fsf@altair.xemacs.org>
References: <199705190436.AAA04788@bayserve.net>
	<m24tc0nk60.fsf@altair.xemacs.org>
	<199705190534.WAA10371@xemacs.eng.sun.com>
	<m2yb9cm1z4.fsf@altair.xemacs.org>
X-Mailer: VM 6.31 under 20.2 XEmacs Lucid
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "sb" == Steven L Baur <steve@xemacs.org> writes:

sb> Martin Buchholz <mrb@Eng.Sun.COM> writes:
>>>>>>> "sb" == Steven L Baur <steve@xemacs.org> writes:

sb> Dynodump is obsolete now,

>> Dynodump is not really obsolete yet - it will continue to be used for
>> dumping on Solaris2.x, x<6.

Well, obsolete in the long run.  Kind of like how sunos4 is obsolete,
but refuses to actually die.

sb> But I thought you told me it was, oh well.  This is even better.  I
sb> cannot maintain dynodump, have no possible way of testing it, and
sb> in fact have done nothing except break it inadvertently while I've
sb> been XEmacs maintainer.

sb> Dynodump is the *perfect* candidate to become the first (c-level)
sb> package.  I'll make up a tarball of it and put it on xemacs.org and
sb> it will be the prototype for the MULE source package.  Basically, a
sb> separately installed tarball that gets untarred over a fresh source
sb> tree.

Removing a component that is *required* to build XEmacs on the most
popular commercial Unix does not strike me as the perfect candidate.
The dynodump directory is only 156k, which makes it insignificant in
terms of total disk usage.  Please leave it in.

sb> I'm preparing some details right now on what I think packages in
sb> general should look like based on the discussion to date.  They're
sb> going to be phased in, but the primitives need to be coded.

>> One of the changes I made was to have "make" completely ignore
>> dynodump on non-Solaris systems.  I didn't do a complete job of
>> this

sb> Yup, been there, been bitten already.  Do you realize how painful it
sb> is to be part-way through a `make distclean', with all your Makefiles
sb> already deleted and have something like that bomb?  Perhaps `make
sb> distclean' can wait until the very final moment to delete Makefiles,
sb> or the top level Makefile anyway?

>> - Makefile.in needs more hacking 

sb> I've stripped the references to dynodump for beta2.  I'll email you a
sb> patch of what I've done, since I've fixed up some other loose ends.

I hate this patch.  I introduced a new variable MAKE_SUBDIR, that
contains a list of subdirs to do makes in.  That should be used
instead.  I'll create an alternate patch.  Removing the dynodump
references is only a workaround.

Martin

