From xemacs-m  Tue Sep  2 20:15:49 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 UAA28700;
	Tue, 2 Sep 1997 20:15:47 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA17149; Tue, 2 Sep 1997 18:15:18 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id SAA14913; Tue, 2 Sep 1997 18:15:15 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA29170; Tue, 2 Sep 1997 18:15:09 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id SAA02808; Tue, 2 Sep 1997 18:15:07 -0700
Date: Tue, 2 Sep 1997 18:15:07 -0700
Message-Id: <199709030115.SAA02808@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: SL Baur <steve@xemacs.org>
Cc: xemacs-beta@xemacs.org
Subject: Re: [Q] The best way to build/install XEmacs for different binaries?
In-Reply-To: <m2lo1f39hn.fsf@altair.xemacs.org>
References: <199709020743.KAA24937@merlin.ornet.co.il>
	<bylo1gxbv4.fsf@midget.math.ethz.ch>
	<m2lo1f39hn.fsf@altair.xemacs.org>
X-Mailer: VM 6.33 under 20.3 "Vienna" XEmacs  Lucid (beta14)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

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

sb> A handful of miscellaneous comments ...
sb> Jan Vroonhof <vroonhof@math.ethz.ch> writes:

>> If you want to compile for multiple architectures you should use the
>> SRC dir option. It makes life much much easier. Even if it involves a
>> recompile of your sunos binaires.

sb> Yes.  It is a supported option that if you upgrade the source --srcdir
sb> points to, you can upgrade the XEmacs source (via patching, or a total
sb> reinstall), then run `./config.status --recheck' for subsequent builds.

>> Go to your fastest machine:

sb> Always a good idea. :-)

>> make distclean (cleanout old stuff)

sb> I don't recommend using `make distclean'.  That is primarily for the
sb> maintainer prior to generating tarballs for distribution.  `make
sb> clean' is better.

I disagree, and am surprised that you wouldn't recommend `make
distclean' for the explicit job of returning to that pristine
just-untarred state.  From the GNU coding standards:

`clean'
     Delete all files from the current directory that are normally
     created by building the program.  Don't delete the files that
     record the configuration.  Also preserve files that could be made
     by building, but normally aren't because the distribution comes
     with them.

     Delete `.dvi' files here if they are not part of the distribution.


`distclean'
     Delete all files from the current directory that are created by
     configuring or building the program.  If you have unpacked the
     source and built the program without creating any other files,
     `make distclean' should leave only the files that were in the
     distribution.

From the above you can see that if you build some *other* GNU program
that has a config.cache, and you do a `make clean; make' on another
architecture, you will be quite thoroughly screwed.  It is from having
burned myself this way that my deep seething hatred of config.cache
first arose.

Unfortunately, `make distclean' is not supported by enough GNU
software to be reliable yet, but it's getting better.  And `make distclean'
does work on XEmacs.  (Yes, I've broken `make distclean' more than
anyone, but that's in the past now :-)

sb> (I've never used `make *arch*')

I do it all the time... works great.


sb>  ...
>>> - What about common stuff.. Is influenced by the configure
>>> differences? (SunOS without CDE, Solaris without NAS, etc.)

>> Not really. There are propably some differences if you compile one
>> with mule and one without it. As far as I know all .elc are compiled
>> always (except for mule).

sb> If you are building mixed Mule/Latin-1 binaries, always rebuild the
sb> lisp with a Mule XEmacsen.  If you are using solely Mule or Latin-1
sb> it doesn't matter.  Rebuilding lisp with a Latin-1 XEmacsen is a new
sb> feature with 20.3, so there may be problems with specific betas,
sb> however it is intended that 20.3-released will support this fully.[1]

>> There is a danger this may change because of compile time featurep
>> checking becoming more and more prevalent.

sb> Yes, but following the rules I gave above should work.  If they don't
sb> it's a bug we'll fix.

sb> Footnotes: 
sb> [1]  Or it won't be released until it does.


