[Help-smalltalk] Re: distributing smalltalk code with C bindings

[Paolo Bonzini]

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