Cross-compiling ruby

I want to build ruby in a cross-compile mode in which the results of a comp=
ilation are installed in some arbitrary directory, then are placed in an ar=
chive, then are unpacked from the archive in their final location on a larg=
e number of machines.  The --prefix option of the configure script can be u=
sed to change the final destination, but it is overloaded to be both the co=
mpile-time destination and the runtime search path.  In my case, these are =
distinct.  Furthermore, the build must run without root permission (and I w=
ould not want to corrupt an existing installation anyway), the final locati=
on requires root permission for writing, and the result of "make install" i=
n my sandbox will not be available on most of the machines on which the arc=
hive is installed.

To illustrate the problem, I run a build as normal user in /sandbox/ruby/sr=
c, and install the results in the /sandbox/ruby/install tree where the bin,=
 lib, share, and other directories are created.  I run this procedure:

mkdir -p /sandbox/ruby/install
cd /sandbox/ruby/src
./configure --prefix=3D/sandbox/ruby/install
make
make install
cd /sandbox/ruby/install
find . -print | cpio -o > /sandbox/ruby.cpio

Now I install the archive on the target machine:

scp /sandbox/ruby.cpio remote:~/ruby.cpio
ssh remote
su
mkdir -p /usr/foo
( cd /usr/foo && cpio -id ) < ruby.cpio

This is a simplified illustration of the method; the actual procedure is mo=
re complicated than this.  The src tree of the sandbox is actually read-onl=
y so the build results are actually deposited elsewhere.  Additionally, rub=
y is only one of several products built in this sandbox, and the whole thin=
g is wrapped in a complicated make-based procedure.  There may even come a =
time when I must build ruby with an actual cross-compiler targeting a diffe=
rent architecture than the build machine, for an embedded system that has n=
o ability to develop software.  But the above presents the relevant aspects=
 of the method.

The issue is that programs like gem have hard-coded into them the location =
into which the "make install" step deposited them.  If you run "gem environ=
ment", you see that it expects the location of the ruby executable to be /s=
andbox/ruby/install/bin/ruby, and the search paths are similarly set.  Note=
 that the sandbox is not available on the remote machine.

Granting permission to install into /usr/foo on the build machine is not an=
 option because it's a production environment and we can't even temporarily=
 corrupt that location while other procedures are running.  And we don't wa=
nt to copy the world into a chroot environment for the purpose of building =
this sandbox.  (That would not work anyway because ruby isn't the only thin=
g that gets built in that sandbox, and other things require an intact /usr/=
foo tree.)

So, how do others build and operate ruby in an environment like this?

P.S.  Having a tool invoke a prior version of itself to build itself, as is=
 done with ruby 1.9.2, violates a fundamental tenet of release engineering:=
  You shall not unwind history to reproduce yourself.  I see from the archi=
ves of this list that others have also reported this issue.  When will this=
 oversight be fixed?


This email and any attachments may contain confidential and privileged mate=
rial for the sole use of the intended recipient. Any review, copying, or di=
stribution of this email (or any attachments) by others is prohibited. If y=
ou are not the intended recipient, please contact the sender immediately an=
d permanently delete this email and any attachments.  No employee or agent =
of TiVo Inc. is authorized to conclude any binding agreement on behalf of T=
iVo Inc. by email.  Binding agreements with TiVo Inc. may only be made by a=
 signed written agreement.