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 |
Free forum by Nabble | Edit this page |