I want to build ruby in a cross-compile mode in which the results of a
compilation are installed in some arbitrary directory, then are placed
in an archive, then are unpacked from the archive in their final
location on a large number of machines. The --prefix option of the
configure script can be used to change the final destination, but it is
overloaded to be both the compile-time destination and the runtime
search path. In my case, these are distinct. Furthermore, the build
must run without root permission (and I would not want to corrupt an
existing installation anyway), the final location requires root
permission for writing, and the result of “make install” in my sandbox
will not be available on most of the machines on which the archive is
installed.
To illustrate the problem, I run a build as normal user in
/sandbox/ruby/src, 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=/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
more complicated than this. The src tree of the sandbox is actually
read-only so the build results are actually deposited elsewhere.
Additionally, ruby is only one of several products built in this
sandbox, and the whole thing 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 different architecture than the build
machine, for an embedded system that has no 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 environment”, you see that it expects the location of the ruby
executable to be /sandbox/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 want 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 thing 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 archives 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
material for the sole use of the intended recipient. Any review,
copying, or distribution of this email (or any attachments) by others is
prohibited. If you are not the intended recipient, please contact the
sender immediately and permanently delete this email and any
attachments. No employee or agent of TiVo Inc. is authorized to
conclude any binding agreement on behalf of TiVo Inc. by email. Binding
agreements with TiVo Inc. may only be made by a signed written
agreement.