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
On Tue, Jan 14, 2003 at 11:34:30PM +, Bro1 wrote:
Those libs are binary-only run-time libs if I understand correctly.
Did you evaluate the impact of those C++ libs in respect with gcc 3.2
migration path in sid? They are compiled against old ABI, I think. And the
same for all Kylix
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
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
On Wed, Jan 15, 2003 at 10:08:19AM +0100, Ralf Treinen wrote:
You might want to have a look at how this is done in ocaml (another
ML implementation). In ocaml, the runtime system has been split off
in order to accomodate application packages that are compiled into
ocaml bytecode. Concerning
On Tue, Jan 14, 2003 at 11:34:30PM +, Bro1 wrote:
Those libs are binary-only run-time libs if I understand correctly.
Did you evaluate the impact of those C++ libs in respect with gcc 3.2
migration path in sid? They are compiled against old ABI, I think. And the
same for all Kylix
smlnj-lib : misc libs for sml
At least, I don't want binary packages to be named -lib.
If they are shared libraries, make it
libwhateverX
and read libpkg-guide.
if they are some SML libraries, name them
libsml-whatever-whatever
regards,
junichi
7 matches
Mail list logo