[MLton] Windows ports and paths

[Wesley W. Terpstra]

On Tue, May 03, 2005 at 01:38:06PM -0400, Matthew Fluet wrote:
> With MLBs, we've given users the option of having a .mlton directory,

This sounds interesting, where is this documented?
Or do you just mean .mlton/mlb-path-map?

> so maybe we out to have a simple way for users to default their compile
> options, either with a MLTON_OPTS environment variable or with a
> .mlton/options file.

A much simpler thing to do is have the mlton-script source a config file
from the user's home directory that includes a few shell script variable
definitions.

By the way... This might also make good sense for all of those -target-*
opts. We discussed this before. I think -target-cc-opt sparc '...' is silly.

Why not something as simple as:

#! /bin/bash

# .... handle @MLton and so on ...

args () {
	while [ "$#" -gt 0 ]; do
		opts[${#opts[@]}]="$1"
		shift
	done
}

args -cc gcc
args -cc-opt "-I$lib/include -O1 -fno-strict-aliasing -fomit-frame-pointer -w"
args -link-opt '-lgdtoa -lm'

eval `$lib/platform`
. $lib/flags/$HOST_OS
. $lib/flags/$HOST_ARCH
test -f ~/.mlton/options && . ~/.mlton/options

doit "${opts[@]}"

Then /usr/lib/mlton/flags/x86 contains:
args -cc-opt '-fno-strength-reduce -fschedule-insns ...'

And /usr/lib/mlton/flags/darwin contains:
args -link-opt '-L/usr/local/lib -L/sw/lib -lgmp'

On the other hand, my end goal for MinGW is to not even need msys, just gcc.
In that scenario, there is no /bin/bash to run mlton-script. =)

If you're going to start adding OS stuff to MLBs, please consider 
my alternate feature requests (all of which are aimed at helping mlb 
files hide their implementation):

1. The ability to predicate off the compiler used

   - This way when you need to use some sort of extension you can provide
     alternate implementations for each compiler. Also, you can work
     around compiler bugs.

2. Some sort of versioning scheme like: mgtk.mlb version >= 93

   - The user gets a nice error like 
     "mgtk.mlb is too old (92 < 93) at myprog.mlb:5"
     instead of confusing error messages.
   - This becomes especially important if SML is ever to have libraries
     which internally use other libraries.

3. Support including the name of a library to link against as an MLton
   extension to the MLB syntax. Suggest other implementations do similarly.

   - Coupled with #1 above, it becomes possible to conditionally include 
     a MLton specific .mlb file which pulls in the required libs.

   - I see no reason a user of mgtk.mlb needs to know what GTK+ libraries
     mgtk is using; mgtk should be able to specify this itself and hide it.

The best part of such a scheme in my mind is that it avoids shell scripts
and make for simple applications. This would help a lot for porting apps
to other platforms, for example: native windows.

-- 
Wesley W. Terpstra