packages (was Re: [MLton] syntax error for "_address")

[Matthew Fluet]

> The difficulty is with _export, although part of that difficulty is that we 
> currently have a compilation model for _export that requires it to be keyed 
> to the whole program.  If you are packaging SML and C in a manner that 
> requires _exports, then it might be worth considering moving to a different 
> compilation strategy for _export.  In particular, it would be nice if John 
> could generate his _exports in a way that the generated .h and .c files would 
> not be keyed to the whole program.

Actually, now that I think about it, the .h files shouldn't change from 
one whole-program to another.  Or rather, the part of the .h file relevant 
to a single SML/C library shouldn't change from one whole-program to 
another.  Therefore, I could imagine the following scenario working:

You're trying to build a SML/C library that uses both imports and exports. 
Suppose you have the files:

   lib.mlb:
     a.sml
     b.sml
     ...

   aux.c:
     #include "lib.h"
     ...

Now aux.c needs the exports of lib.mlb; but, it shouldn't need the exports 
of any other SML/C library that contributes to the end user's whole 
program.  So, it should be sufficient to do:

   mlton -export-header lib.h lib.mlb
   gcc -o aux.o aux.c

(You might delay these until an install step on the end user's system; 
but, nonetheless, it needs to be done only once, not once for each 
program.)

Now a program that makes use of lib.mlb needs only ensure that the 
top-level invocation of mlton passes the right linker flags to pick up 
aux.o.  And, now, this is essentially the same work as is needed when the 
program makes use of a library that only uses _import.  Hence, I think 
that the Makefile include idea of  MLTON_FLAGS += ...  is again 
sufficient.