From: Matthew Flatt <mflatt@cs.utah.edu>
To: plt-scheme@list.cs.brown.edu
Subject: [plt-scheme] 301.16
Date: Wed, 24 May 2006 13:44:20 -0600

MzScheme and MrEd are now version 301.16 in the SVN repository trunk.

This is most of the last step that I promised in the 301.15
announcement:
 http://list.cs.brown.edu/pipermail/plt-scheme/2006-May/013023.html

Changes:

 * Under Unix, when you create a executable with `mzc --[gui-]exe’,
   the resulting executable is a wrapper for MzScheme or MrEd, instead
   of a copy of the MzScheme of MrEd executable.

   This change may seem like a step backward, because it makes the
   generated executable dependent on another executable. However, this
   change is consistent with the fact that generated Windows and Mac OS
   X executables are dependent on shared libraries --- as are Unix
   executables when built with --enable-shared.

   To get the old behavior back, use mzc’s new --orig-exe flag, but
   probably you want the next bullet, instead...

 * Added a new mode to the mzc: --exe-dir. Given a target directory and
   one or more executables generated with --[gui-]exe, it combines the
   executables with any needed DLLs, frameworks, or shared libraries,
   so that the resulting package can be moved to any machine.

   For Windows, executables are put directly into the package
   directory, and DLLs go into a "lib" sub-directory.

   For Mac OS X, MrEd executables go into the package directory,
   MzScheme executables go into a "bin" subdirectory, and frameworks go
   into a "lib" sub-directory. As a special case, if the package has a
   single MrEd executable, then the "lib" directory is hidden inside
   the application bundle.

   For Unix, executables go into a "bin" subdirectory, shared libraries
   (if any) go into a "lib" subdirectory, and the wrapped executables
   are placed into a "lib/plt" subdirectory with version-specific
   names. This is consistent with FHS, and it means that packages can
   be safely unpacked into, say, /usr/local.

   The package also has a "collects" directory that is used as the main
   "collects" for the packaged executables. Currently, the "collects"
   directory is empty, but mzc will soon let you supply directories to
   populate the package’s "collects" directory. In particular, you’ll
   be able to package multiple executables that share collection-based
   libraries.

   The "collects" directory is in "lib/plt/<X>", where "<X>" is the
   name of the first packaged executable (sans suffix). Again, the
   "<X>" means that packages with potentially colliding collections can
   be safely unpacked in the standard place.

   The Scheme interface to the new functionality is in
   "distribute.ss" from the "setup" collection.

 * An executable created with --[gui-]exe ignores PLTCOLLECTS and the
   user-specific "collects" directory, because an executable packaged
   for separate distribution shouldn’t act like part of a PLT Scheme
   installation. To get the old behavior back, use --ccf -U.

 * Added `use-user-specific-search-path’ and a -U command-line flag to
   MzScheme/MrEd. These are used in the implementation of the previous
   bullet.

 * `system-type’ now accepts an optional symbol argument --- one of
   ’os, ’machine, or ’link --- instead of an optional boolean.

Matthew