[plt-scheme] `make install' and DESTDIR

I have made it possible to use DESTDIR for `make install'.  (I hope I
got everything right.)  The thing that you need to keep in mind is
that using it will eventually give you an installation that is
unusable until it is install in its intended place.  Here is a
(relatively) short explanation that I originally wrote to Gérard, and
would be relevant to packagers (feel free to ignore it if you're not
into packaging):

Once MzScheme/DrScheme start, they need to find the collects tree,
obviously.  This step is done right at the start.  Once the collects
are found, Scheme code that deals with files in the "PLT Hierarchy"
should use information from the config collection (see
collects/config/doc.txt) which specifies where the different
directories are -- bin, doc, include, etc -- but not collects, since
the collects tree is needed to find the configure file in the first
place.

The way the the binaries find the collects path is by a path that is
hard-wired into the executables (mzscheme/mred) -- this path can be
either absolut, or relative -- to the executable's own directory.  The
default build is: everything goes into the plt directory, and the
embedded path is "../collects".  Because it is relative, the whole
tree can then be moved elsewhere and things work as they should.
(Also, the config file is empty, indicating that additional things are
in the usual place relative to the collects tree).

However, if you use --prefix, then the resulting installation spreads
files according to FHS conventions, and it doesn't make sense to use
relative paths anymore.  Therefore, the binaries (mzscheme and mred)
will have the absolute paths embedded in them, and the
"config/config.ss" file will have the various directories listed as
absolute paths.

There is a third place where these paths appear -- in launcher
scripts: in a default (in-place) installation, these scripts will find
the binary relative to their own location (you can see the search code
at the top that resolves symlinks; this will not work if you copy
these launchers outside the plt tree).  In a unix-style (--prefix)
installation, launchers have a simple `bindir=...' for the binaries.

The problem with using DESTDIR is that the PLT tree is distributed in
some place (say /tmp/plt-build/usr/...), but is intended to be moved
to a different place (/usr/...).  The solution is for `make install'
to perform one last step for this kind of installation: it will patch
up the installled contents (in /tmp/plt-build/usr/...) so it is ready
to be moved to the real target (/usr/...).  This process deals with
the three locations that needs to be updated: the embedded path in the
binaries, the path in launcher scripts, and collects/config/config.ss.

Once patching is done, the installation will not function properly
until moved (to /usr/... in this example).  You *could* get some
limited functionality by using the `-X' flag, for example:

  mzscheme -X /tmp/plt-build/usr/lib/plt/collects

but this won't work too well -- there is a lot of code that depends on
the (now bogus) information in collects/config/config.ss.  If you
really have to, it is probably better to use `-x' to disable setting
any collection path, and running things that don't depend on
collections.

Final notes:

1. This information is relevant for packages -- for private
   installations, `make install' will work fine with a `--prefix'ed
   configuration, and without `--prefix' things are as simple as
   before (a single plt tree which you can just erase) except a little
   better (it can now be moved to other places).

2. The patching is done by the same script that is in charge of making
   a unix-style distribution by the sh installers (which is turning a
   relative in-place distribution to an absolute FHS-style one).  This
   script (collects/setup/unixstyle-install.ss) can be extended for
   other situation that you might encounter, mail me if you run into
   related problems.

3. If you're creating packages, please don't try to hack paths
   yourself -- the above three places (binaries, launchers, config)
   are the only ones that need to be modified now, but this might
   change in the future.  By piping such changes through
   unixstyle-install.ss, we can extend this set if needed (hopefully
   not).

4. I apologize for completing this now, I didn't know about DESTDIR
   before v350 came out.  If you want to use this for a 350 package,
   then you need to grab the recent versions of the relevant
   Makefile.in, and unixstyle-install.ss and additional relevant
   files.  The relevant files that you can get from svn now (rev 3470)
   are:

     collects/setup/unixstyle-install.ss
     src/Makefile.in
     src/README
     src/mred/Makefile.in
     src/mred/gc2/Makefile.in
     src/mzscheme/Makefile.in
     src/mzscheme/dynsrc/Makefile.in
     src/mzscheme/gc2/Makefile.in

   I can package this up in a single tgz if anyone is interested.  (If
   you add these files on top of the v350 sources, the result is still
   a valid v350 package.)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!