Part 7: Pack Up Your Troubles

Back when I first started using Smalltalk, packaging was an arcane activity that, on the project I was involved with, took 12 hours to produce the final image. Nowadays, packaging a VA Smalltalk image can be as simple as choosing ‘Create Executable Image…’ from the menu of the Organizer window and clicking through some choices until the final packaged image is produced. Sadly, the simple approach is only for simple cases. Once an application becomes a little more complex, this just doesn’t cut it anymore, and we end up creating a class to hold packaging rules, and an application to hold the class, and even packaging methods in application classes to deal with various peculiarities to the point where some of the arcana now are almost as bad as the early days.

As well, those of us who have been forced to deal with packaging for a while have developed our own unique prejudices; some may have lost their validity over the years, but others still have merit. In my case, I absolutely insist on packaging from a virgin image into which only the code absolutely required to run the application has been loaded. I want to load one, and only one, config map that will let me begin my packaging operation, I package only one runtime in that image, and then I throw away the packaging image when I’m done. My goal through all of this is to be able to recreate a given release of an application at any time, and this allows me to do this as long as I have the necessary version of VA Smalltalk installed.

Since I also insist on being able to get to a given release of a development environment with a single config map load, I have to organize my config maps in a particular way to stay DRY. For any given application, I actually have three config maps defined. There is a base config map that sets up all the Smalltalk applications and prerequisites required to actually run my application. I should be able to load and run in an unpackaged environment with that map. Then, I have a development map that loads the base map and everything else needed to set up the development environment the way I like it. Finally, I have a packaging map that loads the base, and anything needed to package, including the Smalltalk application that includes the packaging rules class.

This approach has served me well for a long time. By not loading development tools unnecessarily for packaging, it’s much easier to identify those cases where developers have inadvertently referenced classes or methods that won’t make it into the runtime, and keeps down the number of packaging rules needed to keep out development tool methods that the packager thinks ought to be included. One of my challenges has been third-party tool vendors that haven’t separated their tools into runtime and development components (I’m looking at you, GemStone!). In those cases, whenever a new release comes in, I’ll do the separation myself, but I dislike having to modify third-party distributions.

XD packaging adds an interesting level of complexity that we’ll visit next time.

Advertisements

0 Responses to “Part 7: Pack Up Your Troubles”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: