[MLton] Support for link options in ML Basis files

[Matthew Fluet]

> I just had -L/usr/lib/mlton/sml/sdl because I generete a sdl.a library.

O.k.  I guess it is reasonable that some C-interface libraries may include
their own C-code stubs, which would naturally be distributed as a .a
library, and keeping it alongside the .mlb might be as good a place as
any.

> It contains some functions my bindings use for diassembling the event
> structures returned by SDL into SML values. I suppose it would be better
> to give it a name such as libmlton-sdl.a and stick it in the standard  C
> library path ($prefix/lib) and then add -lmlton-sdl to the Libs.

I don't think it makes sense for libmlton-*.a libraries to be scattered in
/usr/lib.  Virtually nothing besides mlton would ever want to link with
those libs.

> The main point of using
> pkgconfig is that it is better than using some common convention for
> gathering compile flags than using Makefiles or something else along
> those lines.
> ...
> The following convention for using a MLton package would work quite well.

So, you simply replace one convention with another convention.

I'm being a bit of a Devil's Advocate here; I don't disagree that
pkgconfig is trying to solve a legitimate problem.  I'm simply playing the
other side to ensure that we don't commit to something that isn't a true
solution to the problem at hand.

> For package users:
> include in your mlb:
>    $(SML_LIB)/$package/$module.mlb
> compile with:
>    -link-opt `pkg-config --libs mlton-$package`

To be honest, this is only a minor improvement over the initial problem.
It is still the programmer's burden to realize that by including one thing
in the .mlb, they need to include another thing in their Makefile;
regardless of what that other thing is.

> One last question. Awhile ago I started writing a simple program that
> took definitions of C structs and generated a C program which printed
> the offsets of the fields using C's offsetof macro. It then generated a
> program which used functions in the MLton.Pointer structure to unpack a
> MLton.Pointer.t to a SML record equivalent to the C structure.
>
> I see you are working on NLFFI, should I bother finishing it?

I don't see any reason to abandon a tool that you find useful, unless you
find NLFFI more useful.

Currently, I have the entire mlnlffi-lib "ported" to MLton, which
essentially amounts to using the MLton.Pointer structure in the
appropriate places and using MLton's FFI to interface with dlopen and
friends.  What is currently missing is robust port of the mlnlffigen tool.
I have a simple-minded port of the tool, although it is a bit rough in
places.  There are a few issues:

 * the SML/NJ version of the tool knows that it will use CM;
   therefore, it doesn't order the generated files by def-use order;
   the MLton version of the tool will use the MLB system;
   therefore, it needs to order the files in def-use order.
   - I've currently done this in the very hacky manner of (essentially)
     watching the pretty-print output stream for structure references,
     thereby building up a dependency graph, which is topologically
     ordered to produce the correct file order.

 * MLton's FFI isn't expressive enough to pass a struct/union from ML to
   C.  I can fake it on the x86 because the calling convention is to pass
   the struct "in pieces", so one can simulate the call by extracting the
   struct fields and passing them in order.  Unfortunately, this doesn't
   work on all architectures.  Also, it can lead to circular
   dependencies, on something like:

     struct baz {
        int i;
        real r;
        int (*f)(struct baz);
     }

   where the RTTI for the f field requires the struct definition, and the
   RTTI for the struct requires the RTTI for the f field.

   SML/NJ avoids this problem entirely by encoding the (simplified)
   C-prototype in an ML-type, and then letting the backend decode the
   ML-type to a C-prototype and generate the correct calling convention.
   Obviously, this can be a bit of work, and appears to be the main reason
   that NLFFI hasn't been ported to more architectures in SML/NJ.

 * mlnlffigen also has it's shortcomings, independent of MLton.  The most
   glaring of which is that it doesn't export #define constants.  It is a
   recognized problem, but as of right now there doesn't appear to be a
   solution out there.  I suspect it requires modifying the ckit Library.