[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] Re: distributing smalltalk code with C bindings
From: |
Paolo Bonzini |
Subject: |
[Help-smalltalk] Re: distributing smalltalk code with C bindings |
Date: |
Fri, 17 Nov 2006 16:21:55 +0100 |
User-agent: |
Thunderbird 1.5.0.8 (Macintosh/20061025) |
Robin Redeker wrote:
Hi,
I currently have a set of files where i have a file that
loads all required packages and files in the other source files,
is this the normal way to go? Or should i rather put all the source
in a image and distribute that?
Are the images gst writes platform-portable/binary compatible?
eg. when writing a image on my amd64, will it work fine on my
32bit platforms?
They should be okay between 32-bit platforms, but not from 32-bit to
64-bit or viceversa.
I'm sorry for so many questions, but this bugged me for some days now
and i only saw this big packages.xml in the source tree and wondered
whether this is the only place to add packages. And i was unable to find
documentation about it yet.
There is documentation about it in the GNU Smalltalk manual.
To quickly answer your question, the language libraries are better
distributed in source form. The idea is that "make install" could
execute the gst-package script to install a package, after installing
the required libraries and Smalltalk source files.
Having the ability to extend a gnu smalltalk installation by copying a
tar ball and running 'make install' would ease software distribution
a lot. Like it does for Perl, which strenght is the large codebase at
CPAN, where additional modules are easily installable in a blink of an
eye (or mostly running 'cpan' and typing 'install <module name>').
Actually, the community was so small that the need was never important.
But now we start to need it. There are two separate steps to it:
A) network support
A.1) include an URL in the packages file.
A.2) make PackageLoader able to download the tar files, using the
NetClients packages (in particular the URIResolver, see
#openStreamOn:ifFail:).
A.3) use VFS to look in the tar or zip file, and install the files in
the appropriate paths
B) improve packages.xml support within the image, to ease installation
of packages using the above infrastructure (and without rewriting the
infrastructure as a shell script...)
B.1) create a PackageCollection class in kernel/PkgLoader.st that acts
as a "composite" and sits between PackageLoader and Package
B.2) modify the build system so that, if a package is not always
enabled, it is merged in an existing packages.xml file (instead of
having disabled-package). Then remove support for disabled-package (see
comment in #rebuildPackageFile).
B.3) rewrite gst-package in Smalltalk. :-)
Paolo