Re: [Sml-implementers] compilation management

[Matthias B. <bl...@re...>]

Andrew Kennedy wrote:
> 
> A point related to compilation management is that of "entry points".
> Different compilers have different means of indicating where the
> entry point to a standalone executable is, and this is a source of
> incompatibility when trying to compile SML'97 sources under different
> compilers. I can think of at least three:
> 
> (a) Use-style, where "main" is essentially defined by side-effecting
> top-level definitions (e.g. val _ = run_my_program()).
> 
> (b) C-style naming convention for the main function (e.g. fun main() =
> ...).
> 
> (c) Compilation environment directive e.g. SML/NJ's exportFn command.
> 
> It would be nice to agree on something here to save us all writing
> wrapper code every time.

For those who are not aware of this, here is what SML/NJ implements these
days.  Maybe we can take this as a blueprint of what we want to do...

We have a shell command "ml-build" which takes three arguments:

   ml-build <library> <functionname> <executable>

The <library> is a .cm-file, and <functionname> is the name of a function
exported from <library>.  Its type must be

       string * string list -> OS.Process.status

i.e., the type of "main". Finally, <executable> is the name of the stand-alone
program to be constructed.  In our case it currently names a heap image, but
in the future it will probably name a genuine executable.

The command ml-build will invoke the SML/NJ compiler (including CM), build the
library in question if it was not already up-to-date, and then produce an
executable with main entry point <functionname>. Internally, we use exportFn
to establish the entry point, but this is hidden from the programmer and might
even change in the near future.

Maybe we can agree on something similar to the above, i.e., something that does
not make specific claims about implementation details...

Matthias