From xemacs-m  Fri Feb 14 19:39:12 1997
Received: from steadfast.teradyne.com (steadfast.teradyne.com [131.101.1.200])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id TAA27707
	for <xemacs-beta@xemacs.org>; Fri, 14 Feb 1997 19:39:07 -0600 (CST)
Received: from kiki.icd.teradyne.com (kiki.icd.teradyne.com [131.101.1.30]) by steadfast.teradyne.com (8.7.1/8.7.1) with ESMTP id UAA29815 for <xemacs-beta@xemacs.org>; Fri, 14 Feb 1997 20:42:20 -0500 (EST)
Received: from spacely.icd.teradyne.com (spacely.icd.teradyne.com [131.101.10.9]) by kiki.icd.teradyne.com (8.7.1/8.7.1) with SMTP id UAA25776 for <xemacs-beta@xemacs.org>; Fri, 14 Feb 1997 20:36:15 -0500 (EST)
Received: from spacely by spacely.icd.teradyne.com (SMI-8.6/SMI-SVR4)
	id UAA29132; Fri, 14 Feb 1997 20:39:01 -0500
Message-Id: <199702150139.UAA29132@spacely.icd.teradyne.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: xemacs-beta@xemacs.org
Subject: Re: Multiple Architectures 
In-reply-to: Vladimir.Ivanovic's message of Fri, 14 Feb 1997 17:13:18 -0800.
	     <199702150113.RAA15257@lungo> 
reply-to: acs@acm.org
X-Attribution: Vin
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 14 Feb 1997 20:39:01 -0500
From: Vinnie Shelton  <shelton@icd.teradyne.com>

Vladimir, you lost me.  I posted my reply because I was afraid you were
going to confuse the original poster.  If the literal option
'--run-in-place' is not going to be supported, the correct way to support
multiple architectures is something like this:

cd xemacs-xxxx
mkdir SunOS Solaris

on SunOS machine
cd SunOS
../configure --srcdir=.. [other config options]

on Solaris machine
cd Solaris
../configure --srcdir=.. [other config options]

yes, autoconf2 supports this kind of 'run-in-place'.
Martin, I'm still disappointed that I don't end up with all the binaries 
in one place *unless I do a 'make install'*, which is a very long process, 
and chews up disk space.

vin.

> As long as the "run-in-place" functionality is kept, I don't really care
> about the particular implementation.
> 
> Martin's solution allows arbitrarily named build trees which is better
> than run-in-place.
> 
> BTW, does Autoconf 2.x support run-in-place?
> 
> -- Vladimir
> 
> >>>>> Martin Buchholz writes:
> 
> >>>>> "Vinnie" == Vinnie Shelton <shelton@icd.teradyne.com> writes:
>   Vinnie> I believe Martin removed --run-in-place for 20.0.
> 
>   MB> I did, and I still haven't seen a compelling reason to put it back.
>   MB> For sure we want the functionality of being able to run with one
>   MB> source tree and mulitple binaries using that tree, but using the
>   MB> `--run-in-place' option together with `make install' seems highly
>   MB> unintuitive - I had never imagined anyone would do that...
> 
>   MB> The way I use to have multiple `run-in-place' binaries sharing the
>   MB> source tree is like this:
> 
>   MB> srcdir=`pwd`/xemacs-20.0
>   MB> configure="$srcdir/configure --srcdir=$srcdir"
> 
>   MB> mkdir sparc-us   && cd sparc-us   && $configure ... && make
>   MB> mkdir sparc-mule && cd sparc-mule && $configure --with-mule ... && make
> 
>   MB> Then I can just directly run the binary immediately after it's built.
> 
>   MB> Maybe we should document this as the standard solution for XEmacs
>   MB> developers and beta testers.
> 
>   MB> Of course, I do this so often I have lots of other little timesavers
>   MB> to manipulate my build trees.
> 
>   MB> Martin
> 
>   >>> There's an even easier solution.  From the XEmacs root directory:
>   >>> 
>   >>> ./configure --run-in-place
>   >>> make install
>   >>> bin/${CONFIG}/xemacs
>   >>> 
>   >>> Separate configuration directories are created in bin and lib-src for the
>   >>> architecture-dependent executables.  All other files are shared, including
>   >>> Emacs-Lisp, man and info files.
>   >>> 
>   >>> -- Vladimir
>   >>> 
> 


