racket/src/worksp
Eli Barzilay 0686dd721e Welcome to a new PLT day.
svn: r14194
2009-03-20 07:50:38 +00:00
..
extradlls dlls are in PLT/lib not PLT 2006-04-25 17:25:45 +00:00
gc2 windows socket-wait rewrite 2009-03-11 22:08:32 +00:00
jpeg 352.2, including clean up of MSVC 8.0 build warnings 2006-07-31 13:06:39 +00:00
libmred windows socket-wait rewrite 2009-03-11 22:08:32 +00:00
libmysterx msvs9-friendly patches; preliminary splicing let-syntax library; export and doc GC_resolve and GC_fixup_self 2008-09-15 19:08:50 +00:00
libmzgc 352.9 2006-10-30 01:24:08 +00:00
libmzsch windows socket-wait rewrite 2009-03-11 22:08:32 +00:00
mred Welcome to a new PLT day. 2009-03-20 07:50:38 +00:00
mrstart fix Windows memory-limit detection, and fix MrEd Windows console output for things like dump-memory-stats 2007-03-08 01:55:30 +00:00
mzcom Welcome to a new PLT day. 2009-03-20 07:50:38 +00:00
mzscheme Welcome to a new PLT day. 2009-03-20 07:50:38 +00:00
mzstart 352.9 2006-10-30 01:24:08 +00:00
png 352.2, including clean up of MSVC 8.0 build warnings 2006-07-31 13:06:39 +00:00
starters Welcome to a new PLT day. 2009-03-20 07:50:38 +00:00
wxme 352.2, including clean up of MSVC 8.0 build warnings 2006-07-31 13:06:39 +00:00
wxs 352.2, including clean up of MSVC 8.0 build warnings 2006-07-31 13:06:39 +00:00
wxutils 352.2, including clean up of MSVC 8.0 build warnings 2006-07-31 13:06:39 +00:00
wxwin 352.2, including clean up of MSVC 8.0 build warnings 2006-07-31 13:06:39 +00:00
zlib 352.2, including clean up of MSVC 8.0 build warnings 2006-07-31 13:06:39 +00:00
build.bat v3.99.0.2 2007-11-13 12:40:00 +00:00
mzconfig.h fix 3m bug relted to the deep end of a stack-segment copy 2006-07-04 14:46:08 +00:00
README typo (PR9994) 2009-01-02 12:36:32 +00:00

This directory contains 

 - solution files and project files for building MzScheme and MrEd
    with Microsoft Visual Studio 8.0 and up (which work with the
    Express 2005 version of Visual Studio);

 - mzconfig.h which is a manual version of information that is
    gathered automatically when using the "configure" script;

 - scripts for building 3m variants of MzScheme and MrEd using
    Visual Studio command-line tools; and

 - solution files and project files for building MzCOM and MysterX
    with Microsoft Visual Studio 8.0 (not Express, which doesn't
    support ATL and MFC).

Visual Studio Express is available for free from Microsoft; it can be
used to build MzScheme and MrEd, but not MzCOM and MysterX.

MzScheme and MrEd also compile with Cygwin gcc (a free compiler from
GNU and Cygnus Solutions), but the result is a Unix-style
installation, not a Window-style installation. To compile with gcc,
follow the instructions in plt\src\README (which contains a short
Windows-specific section).

With an MSVC-built MzScheme, compatible extensions can be built with
other compilers. Build with Cygwin and copy the installed plt\lib\gcc
to a MSVC-based build to support Cygwin-built extensions. To support
Borland-built extensions, cd to plt\src\mzscheme\dynsrc and run
mkbordyn.bat (which requires bcc23.exe, of course).

As always, please report bugs via one of the following:
  - Help Desk's "submit bug report" link  (preferred)
  - http://bugs.plt-scheme.org/
  - bugs@plt-scheme.org                   (last resort)

-PLT
 scheme@plt-scheme.org

----------------------------------------------------------------------
Building MzScheme and MrEd
----------------------------------------------------------------------

If you're using MSVC 8.0 (not Express), and if `devenv.exe' is in your
path, then you can just run 
       plt\src\worksp\build.bat
from its own directory to perform all steps up to "Versioning",
including the MzCOM and MysterX steps.

The CGC variants of MzScheme, MzCOM, MrEd, and MysterX can be built
via Visual Studio projects. The 3m variants are built by a Scheme
script that runs the MSVC command-line tools. (See "CGC versus 3m"
in plt\src\README if you don't know about the two variants.)

The 3m build requires some parts of the CGC build:
       plt\src\worksp\mzscheme
       plt\src\worksp\wxutils
       plt\src\worksp\jpeg
       plt\src\worksp\png
       plt\src\worksp\zlib
It's simplest to just build the main CGC solutions, which
automatically build all of the above projects, and then build
3m.

Building MzSchemeCGC and MrEdCGC
--------------------------------

The CGC source code for MzSchemeCGC and MrEdCGC is split into several
projects that are grouped into a few solutions. To build the `X'
solution with Visual Studio, open the file plt\src\worksp\X\X.sln.

To build MzSchemeCGC, build the MzScheme solution in
   plt\src\worksp\mzscheme - makes plt\MzSchemeCGC.exe

   [When you open the solution, it may default to "Debug"configuration.
    Switch to "Release" before building.]

To build MrEdCGC, build the MrEd solution:
   plt\src\worksp\mred - makes plt\MrEdCGC.exe

   [Again, switch to the "Release" configuration if necessary.]

The build processes for MzSchemeCGC automatically builds
   libmzgc - makes plt\lib\libmzgcxxxxxxx.dll and
             plt\src\worksp\libmzgc\Release\libmzgcxxxxxxx.lib
   mzsrc - makes plt\lib\libmzschxxxxxxx.dll and
                 plt\src\worksp\mzsrc\Release\mzsrcxxxxxxx.lib

The build process for MrEdCGC automatically builds
   libmzgc - as above
   libmzsch - as above
   libmred - makes plt\lib\libmredxxxxxxx.dll and
                   plt\src\worksp\libmred\Release\libmredxxxxxxx.lib
   wxutils - makes plt\src\worksp\wxutils\Release\wxutils.lib
   wxwin - makes plt\src\worksp\wxwin\Release\wxwin.lib
   wxs  - makes plt\src\worksp\wxs\Release\wxs.lib
   wxme  - makes plt\src\worksp\wxme\Release\wxme.lib
   jpeg  - makes plt\src\worksp\jpeg\Release\jpeg.lib
   png  - makes plt\src\worksp\jpeg\Release\png.lib
   zlib  - makes plt\src\worksp\jpeg\Release\zlib.lib

In addition, building MzSchemeCGC executes
   plt\src\mzscheme\dynsrc\mkmzdyn.bat
which copies .exp, .obj, and .lib files into plt\lib\, and also copies
DLLs from the "extradlls" directory to to plt\lib\.

Building MzScheme3m and MrEd3m
------------------------------

After MzSchemeCGC and MrEdCGC are built, you can can build 3m
binaries:

 1. Ensure that the Visual Studio command-line tools are in your
    path. You may need to run "vsvars32.bat" from your Visual Studio
    installation, so that PATH and other environment variables are set.

 2. Change directories to plt\src\worksp\gc2 and run

      ..\..\..\mzschemecgc.exe -cu make.ss

The resulting MzScheme.exe and MrEd.exe will appear in the "plt"
directory, along with DLLs libmzsch3mxxxxxxx.dll and
libmred3mxxxxxxx.dll in plt/lib. (There is no corresponding
libmzgc3mxxxxxxx.dll.  Instead, it is merged with
libmzsch3mxxxxxxx.dll.)

Building Collections and Other Executables
------------------------------------------

If you're building from scratch, you'll also want the starter programs
used by the launcher collection to create "Setup PLT.exe". Build the
following solutions:

   plt\src\worksp\mzstart - makes plt\collects\launcher\mzstart.exe
   plt\src\worksp\mrstart - makes plt\collects\launcher\mrstart.exe

   [The "mzstart" and "mrstart" programs have no CGC versus 3m
    distinction.]

Then, set up all the other executables (besides MrEd[CGC].exe and
MzScheme[CGC].exe) by running

   mzscheme.exe -l- setup

This last step makes the .zo files, too. To skip compiling .zos, add
-n to the end of the above command.

If you've already built before, then this step can be simplied: just
re-run "Setup PLT.exe", which was created the first time.

Versioning
----------

[If you're going to build MzCOM and/or MysterX, do that before running
 the version-changing script. See instructions below.]

The obnoxious "xxxxxxx" in the DLL names is a placeholder for a
version number. Embedding a version number in a DLL name appears to
be the simplest and surest way to avoid version confusion.

For local testing, you can use the "xxxxxxx" libraries directly. For
any binaries that will be distributed, however, the placeholder should
be replaced with a specific version.

To replace the "xxxxxxx" with a specific version, run

  mzscheme -l setup/winvers

in a shell.

The "winvers.ss" program will have to make a temporary copy of
mzscheme.exe and the "lib" sub-directory (into the temporary
directory), and it will re-launch MzScheme a couple of times. Every
".exe", ".dll", ".lib", ".def", ".exp", and ".pdb" file within the
"plt" tree is updated to replace "xxxxxxxx" with a specific version
number.

----------------------------------------------------------------------
Building MzCOM and MysterX
----------------------------------------------------------------------

Beware that MzCOM and MysterX do not build with Express versions of
Visual Studio. Otherwise, building MzCOMCGC and MysterXCGC is similar
to building MzSchemeCGC. Building the 3m variants is a little
different.

Building MzCOM
--------------

To build MzCOMCGC, make the MzCOM solution in
   plt\src\worksp\mzcom - makes plt\MzCOMCGC.exe

Use the "Release" configuration.

After building MzCOMCGC, you can build the 3m variant by 

 1. Change directories to plt\src\worksp\mzcom and run

      ..\..\..\mzschemecgc.exe -cu xform.ss

 2. Switch to the "3m" configuration in the MzCOM solution
    (in Visual Studio).

 3. Build (in Visual Studio).

The result is plt\MzCOM.exe.

Building MysterX
----------------

To build MysterXCGC, make the MysterX solution in
   plt\src\worksp\libmysterx - makes plt\lib\myssink.dll,
          plt\lib\myspage.dll, and mxmain.dll in
          collects\mysterx\private\compiled\native\win32\i386

Use the "Release" configuration.

After building MysterXCGC, you can build the 3m variant by 

 1. Change directories to plt\src\worksp\libmysterx and run

      ..\..\..\mzschemecgc.exe -cu xform.ss

 2. Switch to the "3m" configuration in the libmysterx solution
    (in Visual Studio).

 3. Build (in Visual Studio).

The result is mxmain.dll (no 3m suffix) in
  collects\mysterx\private\compiled\native\win32\i386\3m

----------------------------------------------------------------------
Finding DLLs
----------------------------------------------------------------------

Since the DLLs libmzsch3mxxxxxxx.dll (or libmzgcxxxxxxx.dll and
libmzschxxxxxxx.dll) and libmred3mxxxxxxx.dll (or libmredxxxxxxx.dll)
are installed into plt\lib\ instead of just plt\, the normal search
path for DLLs would not find them when running "MzScheme.exe" or
"MrEd.exe". To find the DLLs, the executables are "delayload" linked
with the DLLs, and the executables explicitly load the DLLs from
plt\lib\ on start-up.

The relative DLL path is embedded in each executable, and it can be
replaced with a path of up to 512 characters. The path is stored in
the executable in wide-character format, and it is stored immediately
after the wide-character tag "dLl dIRECTORy:" with a wide NUL
terminator. The path can be either absolute or relative; in the latter
case, the relative path is resolved with respect to the
executable. Replacing the first character of the path with "<"
disables the explicit DLL load, so that the DLLs must appear in the
normal DLL search path.

See also ..\README for information on the embedded "collects" path in
the executables.

----------------------------------------------------------------------
Embedding MzScheme
----------------------------------------------------------------------

The MzScheme DLLs can be used within an embedding application.

The libraries

    plt\lib\win32\msvc\libmzsch3mxxxxxxx.lib
    plt\lib\win32\msvc\libmzschxxxxxxx.lib
    plt\lib\win32\msvc\libmzgcxxxxxxx.lib

which are created by the mzsrc and gc projects, provide linking
information for using the libmzsch3mxxxxxxx.dll, libmzschxxxxxxx.dll,
and libmzgcxxxxxxx.dll DLLs. The versioning script adjusts the names,
as described above.

See the "Inside PLT MzScheme" manual for more information about using
these libraries to embed MzScheme in an application.


If you need MzScheme to link to a DLL-based C library (instead of
statically linking to the C library within the MzScheme DLL), then
compile MzScheme with the /MD flag.