distributing smalltalk code with C bindings

Hi,

i wondered how to best distribute gnu smalltalk code i've written
to other systems (i386 and amd64 architectures for example),
where a recent gst is installed.

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?

And next: What if i want to interact with C libraries, where i wrote
some C glue code for? How to distribute those glue code to the other
systems and compile it there? Should the glue-code be packaged in it's
own manner with a Makefile containing the neccessary build options
(and if this is the case, where do i get the right build options from?)
or is there a way gnu smalltalk will handle that for me (build my C
source files into a library that can simply be used by gst)?

I also wonder if there is a way to install or provide 'additional' packages
to a gnu smalltalk installation. For example: smalltalk code (maybe
with C glue code) packed up in a tar ball together with a .xml
defining the dependencies, and a install script/makefile will copy (and
build) these to a (eg. system wide) location where gnu smalltalk can
simply find it.

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.

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>').

Robin


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk