[MLton] Compiling mlton on MacOS

[Stephen Weeks]

> I have some time now to take another go at compiling mlton on MacOS X.

Great!  I've been thinking of purchasing a little eMac for myself so I
could play around with MLton on it.

> I get a lot further, but I'm hitting the following error:
> 
> 	...
> 	Unknown OS Darwin.
> 	ar rc libgdtoa.a gdtoa/*.o
> 	gcc -Wall -I. -Igdtoa -D_FILE_OFFSET_BITS=64 -fomit-frame-pointer -O2 
> -c -o basis/Array/numElements.o basis/Array/numElements.c
> 	Unknown OS Darwin.
> 	In file included from basis/Array/numElements.c:2:
> 	mlton-basis.h:173:2: #error MLton_Rlimit_virtualMemorySize not defined
> 	make[2]: *** [basis/Array/numElements.o] Error 1
> 	make[1]: *** [runtime] Error 2
> 	make: *** [nj-mlton] Error 2
> 
> Any pointers on fixing this problem?  Thanks.

There are two problems.

1. "Unknown OS Darwin" is reported by bin/platform.  You need to add
an appropriate case to that script.

2. Sprinkled throughout the runtime are #ifdef's for platform specific
code.  The particular one you have hit is for the definition of the
constant MLton_Rlimit_virtualMemorySize, which will become the value
of MLton.Rlimit.virtualMemorySize.  The #ifdef's in the runtime are
written so that you get as much help as possible when porting to a new
platform.  So, they almost always have an #else clause that reports a
compile time error.  You need to to supply an appropriate definition
-- in this case, probably adding "|| defined (__DARWIN__)" or whatever
the symbol is to the *BSD case is the way to go.

Most of the #ifdef's need to be filled in.  However, for a few, like
the time profiling stuff in gc.c, you can delay implementation by
filling in a stub that reports a runtime error, e.g. see line 3817 of
gc.c.

I hope this helps, and look forward to more reports!