Re: [Sml-implementers] compilation management

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

At 05:01 PM 9/18/2001 -0700, Stephen Weeks wrote:
>{stuff deleted}
>Here is my main requirement for a standard compilation management system that
>specifies how to build applications:
>
>>From a description of an application, it should be easy to extract an SML
>program consisting of all and only the modules that are needed for the
>application.  (This extraction may require renaming modules.)  In fact, that is
>one way to define the dynamic semantics of the compilation management system --
>by translating the description of the application into an SML program.
>
>By "easy", I mean that the extraction should be possible without looking at any
>SML sources, only by looking at the application and library description files.

Let's just keep things simple, and get everyone to adopt CM. I've talked to
Matthias in the past about having a "dump everything to one big SML file" 
option for CM. It's not that hard to do. Making CM independent of the 
underlying SML/NJ compiler will probably take some more work, but much less
work than trying to reinvent yet another compilation system.

This suggestion violates Steven's "easy" requirement. However, I think that 
by making things "easy" for the tool it must make things harder for the user.
I'm happy as things are now.. where I just list a bunch of SML files in any
old order in my sources.cm and type CM.make(). 

Even for very larger systems, I see no advantage to having the user provide 
any more information than a list of files and perhaps an export list 
of identifiers.

Anyway, as a first cut someone should take some version of CM and modify it so
that it compiles independently of SML/NJ and simply dumps one big SML source file.
Perhaps, later on we can figure out how to disentangle the current CM from SML/NJ
and have others integrate it into the guts of their systems.

I am a CM bigot... so perhaps there are some strong concrete technical reasons 
I'm ignoring... but unless there are I don't see any reason not to just adopt CM*.

*A question arises about which CM the "classic" version that ships with the stable 
SML release or the new CM. I think, it would be prudent to just stick with the
"classic" version as a first cut, and migrate to the "new" CM later on.