On Tue, Jan 14, 2003 at 08:06:31PM -0800, Aaron Matthew Read wrote: > I am working on a repackaging of the SML/NJ package that splits the > sml runtime component apart from the sml compiler. The idea is to > facilitate the packaging of SML programs and libraries without > requiring the user to install the compiler.
An excellent decision. > My main question is how to name these packages appropriately. Here is the > package naming as of now: > smlnj-runtime : the runtime system > smlnj : the compiler > ml-yacc : sml yacc implementation > ml-lex : sml lex implementation > ml-burg : a code generator generator > smlnj-lib : misc libs for sml > ckit : translate C code to an abstract syntax in SML > exene : an X11 programming interface for SML > ml-nlffi : the "No Longer Foreign Function Interface" > cml : Concurrency support for ML. Are these SML/NJ specific? It might be a good idea to prefix them if they are. Even if they are not, perhaps an sml- prefix would be in order, much like CL packages are prefixed with cl-. A crude namespacing, but it could help. It's debatable whether non-development related applications should have the prefix, but libraries and whatnot should. > Besides the "smlnj-runtime" and "smlnj" packages, all others are named > the same as they are upstream. This is somewhat nice, but I don't think that namespace conflicts are worth having the same name as upstream, if it might be a problem. > Any comments on this naming scheme. Should the "smlnj" package be > called "smlnj-compiler"? When I did this for bigloo, I chose bigloo and bigloo-runtime, but the latter package was merely a branch off of the runtime libraries; not a major package restructuring. I think that this is fine, SML/NJ is a compiler and I would expect the sml-nj package to have the compiler. The -runtime bit is for other packages to depend on, and would probably never be directly installed by a user. One thing you might want to think about is how to play nice with future versions. In other words, if a future version's runtime is not backwards compatible then you will have to arrange a separate package with separate directories. Possibly even a package name with version information, if you want to be able to have both versions installed simultaneously. sml-nj-runtime110.42, etc. One little thing: why smlnj instead of sml-nj, as before? -- ; Matthew Danish <[EMAIL PROTECTED]> ; OpenPGP public key: C24B6010 on keyring.debian.org ; Signed or encrypted mail welcome. ; "There is no dark side of the moon really; matter of fact, it's all dark."
