[plt-scheme] 301.13 pre-installers

The new installers should be working fine, after settling a few major
changes in the way collections are located.  Finish Install (in any of
its names), ./install, and the MzScheme part of the installers are all
gone.  The OSX installer is now a simple drag-and-drop, and the others
are also doing just the directory unpacking with no plt installer
part.  Also, with the PLT tree that you get from these installers, it
should be possible to move them around (modulo Start Menu shortcuts
and extension association on Windows).

Please try them out and let me know if you find any problems.

All of this is possible because of the changes Matthew talked about in
the message below, which I include in full for reference.

(Note: this is not the end of these changes, there is still some work
to do to make it possible to install PLT as a normal application on
Unix -- the function that is mentioned in the third paragraph of
Matthew's message.  When we get there, I might hack on the shell
installers so it is possible to make them do either kind of
installation, but the FHS-friendly changes are mainly aimed for
various platform packagers, and individual from-source installations.)

On Apr 22, Matthew Flatt wrote:
> MzScheme and MrEd are now version 301.13 in the SVN repository trunk.
> 
> This version continues a series of changes that will result in simpler
> installers on Mac OS X and Windows, more flexibility in re-packaging
> PLT Scheme for Unix variants, and better support for creating your own
> stand-alone executables.
> 
> One effect of the changes is that the concept of "PLTHOME" is going
> away. Instead of a root directory that contains all other parts of a
> PLT installation, there will be functions to find the main "collects"
> directory, the "lib" directory, etc., and the locations of those
> directories will be configurable. Those functions are not ready, yet.
> 
> Starting with 301.13, however, MzScheme and MrEd no longer recognize
> the PLTHOME environment variable. The (relative) path to the main
> "collects" directory is embedded in each executable. Eventually, paths
> to other directories (such as "lib") will be embedded in a "config"
> collection.
> 
> Meanwhile, for Unix and Mac OS X, a launcher script refers to an
> executable through a path that's relative to the script itself.
> Combined with the recent changes for Mac OS X to support frameworks
> relative to the executable, this means that the Mac OS X distribution
> can be drag-and-drop, instead of an installer.
> 
> Finally, when creating a stand-alone executable, the path to "collects"
> within the executable can be set (e.g., with mzc's new `--collects'
> flag). This makes it easier to distribute extra files that are needed
> by the executable. Soon, we'll add tools for putting a copy of shared
> libraries with a set of generated executables, so that the resulting
> package is truly "stand-alone".

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