[MLton] compiler dependencies

[Brandon J. Van Every]

Stephen Weeks wrote:
> Brandon Van Every wrote:
> >
> > My rule of thumb is that if a project does not have a VC++
> > build, they
> > aren't serious about Windows development.  Such projects
> > typically have
> > zero people actually compiling, testing, and using things
> > on Windows.
> ...
> > 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++,

In the C/C++ world, some languages and libraries require compilation and
linkage with specific versions of C/C++ in order to be usable.  An
example would be Python, which currently has a VC6 build.  If you want
to use the C FFI for Python, you must link everything with VC6.  The
problem is that mainstream industry standard practice is VC7.1, aka .NET
2003.

From a commercial developer's point of view, the open source guys are
all using compilers from the stone ages.  This kind of hard linkage
requirement (i.e. that's the only way it'll work), soft linkage
requirement (it's going to be lotsa work / invite bugs if you do
differently), and compiler build inertia is endemmic to the open source
community.

One faint ray of hope is that MS does provide a free VC++ sans IDE
nowadays.  On the other hand, maintaining command-line driven NMAKE
files rather than IDE driven .SLN files might be construed as tacky,
unprofessional, or hardcore OS development.  Usually it's the province
of device drivers, i.e. you get the free compiler off the DDK.

A project that actually uses VC7.1 for its build is making a very strong
statement about what kind of Windows support it offers.  That's what you
do if you treat Windows as a first class citizen, with the expectation
of industrial use.

> or that MLton
> can use VC++ when it needs to call a C compiler,

I would think in most instances, if you need to call a C compiler then
you also need to link MLton to C code.  So the above reasoning applies.
The only exception I can think of is autoconf-style deduction of system
characteristics.  Even in that case, the characteristics presented by
Cygwin, MinGW, and VC7.1 are all different.

> or that MLton can use
> the assembler that I assume comes with VC++,

Cross-language use of assemblers is beyond my ken.  :-)

> or some combination of these, or something else?

It's not really so complicated.  Simply put, if the VC7.1 build isn't
there, the support isn't there.  Nobody's bumping into the industrial
problems and nothing's really usable.  There's probably a zillion minor
details where one will find concrete proof of this claim; they're really
not worth eneumerating.

I am not sure if anyone's doing commercially viable work with MinGW.  I
have never made an effort to look up "testimonials and success stories"
about it.  At a glance, www.mingw.org is not oriented towards presenting
that sort of information.  Anecdotally, I've never run into a Windows
professional making use of it.  It's always hobbyists, students, and
academics.  There may be, however, specific niches of development I
haven't investigated.  My statement is certainly true of my problems
though: game development, 3D graphics, and AI.


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

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur