Re: [Sml-implementers] compilation management

[Daniel C. W. <dc...@ag...>]

At 10:27 AM 9/19/2001 -0400, Matthias Blume wrote:
{stuff deleted}

>Obviously, I have a natural bias in favor of CM. :-)  But I actually agree with
>Steve (and others) to some degree.  Getting everyone to adopt CM is a bit too
>ambitious, I think.  More realistic is a simple exchange format that specifies
>precisely which files get compiled in the context of what bindings imported from
>where.  I have ideas as to what this format could look like.  As you might imagine,
>CM internally computes all this information anyway, so dumping it into an
>ASCII file will not be hard at all.
>
>It is my plan to design a low-level format that I believe all SML implementors could
>easily support without having to do fancy things such as dependency analysis etc.
>The format will also provide the necessary information for the transformation into
>pure SML that we described in our TOPLAS paper (where it was also used to define the
>dynamic semantics of CM).

I guess there are two issues.
 1. A portable low-level build script mechanism that is easy for any 
    implementation to adopt, whose goal is to reliably reproduce a build. 
    It really should not be too much fancier than "use" with 
    symbol import and export info. It would be useful if these build scripts 
    can be composed in a limited way like sources.cm files can be.

 2. A standard way to generate these "build-scripts" from source files.

The answer to question 1, should be easy to agree on.

For 2, the long run answer should be CM, because I see no reason to adopt
any other model when the CM model. It is quite well tested and superior to
all the existing approaches in all the existing ML implementations, from
a user standpoint. 

I feel #1 is only a stop-gap until CM becomes a standalone SML program that
can generates these build scripts for all implementations. At that point
the build-script language is just some silly intermediate form that end
users should be completely oblivious to.

In the not to distant future, I hope their is one user visible build mechanism
and it should look a lot like CM. Point 1 should be addressed first  
but at the end of the day point 2 is the only one that matters to end users.