[MLton] Support for link options in ML Basis files

[Stephen Weeks]

> > Can we avoid portability problems by automatically generating a
> > wrapper to translate between the calling convention we understand
> > (n-ary C functions with basic types) and the calling convention we
> > don't (passing C structs)?
> 
> That is an option. 
...
> The problem is that on the ML side, ML-NLFFI always passes structs/unions
> around as pointers.

The approach I proposed seems easier, although both work.  I think the
difference is in who allocates space for the struct.  In my approach,
the struct is allocated on the stack on the C side and then
immediately flattened to pass to the funtion.  In their approach, if I
understand correctly, the struct is allocated on the SML side (using
malloc? or SML/NJ alloc?) and then flattened on the C side to pass to
the function.  Hopefully my approach will be faster because gcc can
optimize away the struct entirely, and just shuffle the args to
translate between the n-ary calling convention and the struct calling
convention.

I guess the problem is that you will have to modify ML-NLFFI to do
this.

> > Might it work to use the same approach that we use for
> > build/lib/<target>/constants?
> 
> Depends what you mean?  I believe the hope is that the programmer doesn't
> need to specify which #define constants should be exported, but that might
> be too much to ask of a tool.

Yeah, it doesn't seem too much to ask for the programmer to specify
which constants they want.