[MLton] Comments on and bugs in build process (powerpc/darwin)

Sean Leather leather at cs.uu.nl
Tue Jun 7 02:10:25 PDT 2011


I have an old PowerBook G4 running Mac OS X 10.5 (Leopard) which I decided
to equip with MLton for building another tool. I looked around the website,
didn't find any binary package, didn't find a package in MacPorts, but found
the source and several claims that it would compile on darwin/powerpc just
fine. I also didn't find any proper documentation on building MLton, so I
thought I'd just run 'make' and see what happens. What follows are some
observations and bug reports.

------------

1. It would help greatly if there was a simple build guide included in the
source. This would have saved me significant time and effort. It should list
the required tools needed and the process for building MLton.

2. I discovered that MLton built with 'make' alone requires 'latex,' which I
did not have, since I recently performed a fresh install of my system.
Perhaps this is only for documentation, but it does seem strange to require
'latex' to build a compiler.

3. I discovered that MLton requires a bootstrapping compiler. Since I did
not find any guide on simply "building MLton," I did not know this. Only
later did I discover SelfCompiling <http://mlton.org/SelfCompiling> . Then,
I have two options (apparently):

3 (a). Find a binary 'mlton' for my system.
3 (b). Install SML/NJ.

I couldn't do (a). One solution to this would be to keep binaries from old
systems on mlton.org like the one announced at
http://mlton.org/pipermail/mlton/2004-September/026105.html in 2004. This
would simplify building newer versions.

I could do (b) since SML/NJ is in MacPorts.

4. There are (at least) two bugs in the $SRC/build/bin/mlton script.

4 (a). The first was mentioned at
http://mlton.org/pipermail/mlton-user/2010-January/001602.html . I got the
following error:

$ ./build/bin/mlton
unknown switch: -fno-common
usage: mlton [option ...] file.{c|cm|mlb|o|sml} [file.{c|o|s|S} ...]
...

After some experimentation, I discovered that this is due to the {-cc-opt
'-O1 -fno-common'} (in between { }) being transformed by bash into {-cc-opt
-O1 -fno-common}, so 'mlton' thinks -fno-common is an argument. I'm not sure
why my bash does this when others' don't. It is fixable (I believe) by
replacing the inner spaces with commas or by passing each flag to -cc-opt
individually (though I don't know how mlton interprets comma-separated or
duplicate flags). Of course, many of the flags in the script are affected,
so it requires a good amount of refactoring.

4 (b). The  second was trickier and uglier. See the following section of
code:

case "$HOST_OS" in
mingw)
exe='.exe'
;;
hpux)
        ia64hpux="-mlp64"
;;
*)
exe=''
;;
esac

Note that this is the only declaration of the variable 'ia64hpux'. Then
observe the next snippet from the arguments to the 'doit' function which
calls '$mlton':

... \
-target-link-opt ia64 "$ia64hpux" \
-target-link-opt mingw \
...

Since I am not on an hpux machine, this resolves to:

... -target-link-opt ia64 -target-link-opt mingw ...

and gives some mighty strange errors.

In my script, I simply inlined $ia64hpux, but there's probably a better way
to fix this. I also wonder why this didn't show up on any other systems.

------------

I haven't yet reached the point where I'm actually using MLton. Smooth
sailing from here, right? ;)

I hope this helps the developers or any future users with similar problems.

Regards,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20110607/34fe555a/attachment.htm


More information about the MLton mailing list