Re: SML-NJ Package Names
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
> 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@example.com>
; 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."