[MLton] compiler dependencies

[Brent Fulgham]

--- Stephen Weeks <sweeks@sweeks.com> wrote:
> ...
> > VC++ is of course standard industry practice.
> 
> Good to know.  I'm still a bit confused (remember, I
> know *nothing*
> about VC++) about what it means to "have a VC++
> build" of MLton.  Do
> you mean that MLton's runtime can be compiled with
> VC++, or that MLton
> can use VC++ when it needs to call a C compiler, or
> that MLton can use
> the assembler that I assume comes with VC++, or some
> combination of
> these, or something else?

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).

GCC's more recent versions produce code that complies
with Microsoft's linking ABI, so lots of MingW code
builds and runs standard windows application examples,
and can be linked with existing windows modules.
 
A good example of a project that supports VC++ is GNU
Prolog, which can be build under Cygwin (to support
the Make environment), but uses VC++ to compile the
software and produces a complete Windows application,
with no Cygwin code linked in.  (Of course, GNU Prolog
is GPL'd itself, so I guess it's a moot point...)

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.

-Brent