[MLton] self-compiling failed

[Matthew Fluet]

On Wed, May 19, 2010 at 9:22 AM, Baojian Hua <huabj at mail.ustc.edu.cn> wrote:
> And the document at
> http://mlton.org/SelfCompiling
> seems a little out-of-date and not very informative for this.

Yes, I glanced at that when you mentioned your difficulties, and agree
that it should be updated.

> Btw: I'm trying to self-compile MLton for that I'm trying to implement
> some new optimizations on SSA IL. In this, I've found that the MLton's
> expert option "-trace" won't work as I expected (it produce nothing).
> A close look at the code reveals that the Assert.debug is set to false, so
> it seems that I should set it and then build a "tracable" version. Is this
> the perfect way to do this? Or else is there another option to control this?

There are two ways to enable the "-trace" option.

It is enabled under a SML/NJ build of MLton.  From the root of the
mlton source tree, a "make smlnj-mlton" will build a SML/NJ heap image
and copy it to build/lib.  The build/bin/mlton script will prefer a
MLton build of MLton over a SML/NJ build of MLton, so be sure to
remove build/lib/mlton-compile.  Because SML/NJ's cutoff recompilation
is faster than MLton's whole program compilation, this is generally
the way I work when debugging something like an SSA IL optimization
pass.

It is also enabled under a MLton build of MLton that uses "-const
'MLton.debug true'".  From the root of the mlton source tree, a "make
traced" will build such a compiler.  (This target to the root Makefile
doesn't build everything, so you should only use it after having first
done a "make".)  Then the build/bin/mlton.trace script will invoke the
mlton-compile.trace executable that has the "-trace" option enabled.
This build also enables exception histories, which is often useful for
debugging.