Part 11: Now you see it, now you don’t…

In the last installment, we scripted the creation of a build specification, and, as a last step, told it to save. Where did it save, and how do we get it back? That’s what we’ll find out today.

Build specifications are stored in the repository using a protocol conveniently provided by OTI back in the dim and hazy days of the past, EmUser>># storeObject:as:, and retrieved using EmUser>>#objectNamed:ifAbsent:. The unique identifier for the object is a string.

If you recall, one of the attributes of a build specification is its #name. I chose to use this as the unique identifier for the build specification both for readability and simplicity. Every build specification has to have a unique name. If you save a specification using an existing name, you’ll overwrite the the one that’s already there, because there’s no versioning mechanism.

There are a number of ways around the lack of a versioning mechanism. Probably the simplest is to put the script fragment creating the build specification into a method in the packaging class, but you’ll have to determine how fancy you need to get based on your own requirements.

You may have noticed that the methods we use to store and retrieve the specifications are instance methods. This implies that there’s a user with whom these build specifications are associated. As distributed, the code I provided associates these objects with Library Supervisor, since every repository has one. However, if you look at EmUser class>>automatedBuildOwner, you’ll find that it’s easy to change the owner to a different user.

Retrieving build specifications is quite simple, and I’ve provided several ways of doing it. You can send #allBuildSpecifications to the class EmUser or to AbtBuildSpecification. You can also retrieve a given build specification by name using EmUser class>>#buildSpecificationNamed:. Check the ‘automated build support’ category in EmUser for many interesting methods, including the ability to delete build specifications.

Of course, the whole point of the exercise is to build something. The AbtBuildSpecification will respond to #build, and create a packaged image. The #build method will load the config map specified in the specification. If it’s an XD specification, it then creates a passive image and loads the necessary code into that. Finally, #build runs through the steps that the packager control panel would have done if you were working interactively, and, if all is well, will produce the packaged image.

Packaging from a script then becomes a fairly simple exercise:

abt -p 'My Build Specification'

will find the build specification named ‘My Build Specification’, load the necessary code, and produce a packaged image based on it. What could be simpler? We can also control the logging of packager output with the ‘-f’ parameter.

abt -p 'My Build Specification' -f myfile.log

And that’s everything you need to know automate your own Smalltalk builds, but not everything I have to say…

Advertisements

1 Response to “Part 11: Now you see it, now you don’t…”


  1. 1 Marten Feldtmann 2011-09-28 at 06:46

    Tom,

    these articles about VASmalltalk scribtable packaging are one of the most remarkable “internal” informations I’ve read about this product over the last years. Congratulations and many thanks for sharing this information.


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: