If you want to compile MLton, you must first get the Sources. You can compile with either MLton or SML/NJ, but we strongly recommend using MLton, since it generates a much faster and more robust executable.
Compiling with MLton
To compile with MLton, you need the binary versions of mlton, mllex, and mlyacc that come with the MLton binary package. To be safe, you should use the same version of MLton that you are building. However, older versions may work, as long as they don’t go back too far. To build MLton, run make from within the root directory of the sources. This will build MLton first with the already installed binary version of MLton and will then rebuild MLton with itself.
First, the Makefile calls mllex and mlyacc to build the lexer and parser, and then calls mlton to compile itself. When making MLton using another version the Makefile automatically uses mlton-stubs.cm, which will put in enough stubs to emulate the MLton structure. Once MLton is built, the Makefile will rebuild MLton with itself, this time using mlton.cm and the real MLton structure from the Basis Library. This second round of compilation is essential in order to achieve a fast and robust MLton.
Compiling MLton requires at least 512M of actual RAM, and 1G is preferable. If your machine has less than 512M, self-compilation will likely fail, or at least take a very long time due to paging. Even if you have enough memory, there simply may not be enough available, due to memory consumed by other processes. In this case, you may see an Out of memory message, or self-compilation may become extremely slow. The only fix is to make sure that enough memory is available.
If you have errors running latex, you can skip building the documentation by using make all-no-docs.
The C compiler may not be able to find the GnuMP header file, gmp.h leading to an error like the following.
platform/darwin.h:26:36: /usr/local/include/gmp.h: No such file or directory
The solution is to install (or build) the GnuMP on your machine. If you install it at a different location, put the new path in runtime/platform/<os>.h.
The following errors indicates that a binary version of MLton could not be found in your path.
/bin/sh: mlton: command not found
make: mlton: Command not found
You need to have mlton in your path to build MLton from source.
During the build process, there are various times that the Makefile`s look for a `mlton in your path and in src/build/bin. It is OK if the latter doesn’t exist when the build starts; it is the target being built. Failure to find a mlton in your path will abort the build.
Mac OS X executables do not seem to like static libraries to have a different path location at runtime compared to when the executable was built. For example, the binary package for Mac OS X unpacks to /usr. If you try to install it in /usr/local you may get the following errors:
/usr/bin/ld: table of contents for archive: /usr/local/lib/mlton/self/libmlton.a is out of date; rerun ranlib(1) (can't load from it)
Although running ranlib seems like the right thing to do, it doesn’t actually resolve the problem. Best bet is to install in /usr and then either live with this location, or build MLton yourself and install in /usr/local.
Compiling with SML/NJ
To compile with SML/NJ, run make smlnj-mlton from within the root directory of the sources. You must use a recent version of SML/NJ. First, the Makefile calls mllex and mlyacc to build the lexer and parser. Then, it calls SML/NJ with the appropriate sources.cm file. Building with SML/NJ takes some time (roughly 10 minutes on a 1.6GHz machine). Unless you are doing compiler development and need rapid recompilation, we recommend compiling with MLton.