[MLton] compiler dependencies

[Brandon J. Van Every]

Brent Fulgham wrote:
>
> It really shouldn't matter what the object modules
> produced by MLton, as long as the C calling
> conventions for the platform are honored.  Brandon
> brings up a lot of issues with the specific version of
> Visual Studio, but in my experience this is really
> only an issue for C++ code, since the name-mangling
> behavior was only recently defined by an ANSI standard
> (and few compilers totally follow it).

Even in C, linking with several runtimes from different compilers is
explicitly stated as a Bad Practice with potential Nasty Consequences.
I forget under what circumstances, it may have to do with threading.  Or
it could have been about competing mallocs.

> I think what Brandon is looking for is some
> confirmation that code produced by MLton (if it could
> produce a library, rather than an executable) could be
> linked into other Windows code without having to
> perform bizarre rituals to do so.
>
> It might also raise his comfort level if MLton could
> be built using VC++.  Efforts to port to MingW would
> obviously be a big step in the right direction.

This is not about my personal requirements or comfort level.  My
interest in MLton is experimental and unproven, I am not relying on it
for anything.  I'm not even relying on SML/NJ yet, that too is
experimental.  I am simply relating what I've learned about the
realities of open source build procedures and industrial acceptance on
Windows.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie