BodyBuilder

Look at Recent Changes to watch this wiki develop (RSS here).

This wiki is a companion to the BodyBuilder project at SourceForge.

If you want to follow the development sign up to the mailing list.

If you want to contribute you must be free to 'give away' your code since the BodyBuilder license is the famous 'new BSD' license.

Packaging BOF at Smalltalk Solutions 2006.

This wiki is currently empty, running up to StS2006 I hope to post the various scripts people have sent me as example of their current build automation. I also intend to provide a description of the PackageBot client/server system in use at Soops which is in dire need of a redesign.

For the moment I'll simply point you to SCons which is a system that shares several properties with what I have in mind for BodyBuilder.

A list of other interesting build systems.

If you (or your shop) has done any significant build automation on VW I would love it if you created a page here with a short 'war story' on what you have, how you use it and snags encountered. Even if you don't intend to join the BodyBuilder project I would greatly appreciate it if you write up your experiences here so we can get a feel for what is desired. See the Wiki Syntax page for editing hints.

Existing solutions/war stories:

• PackageBot (Soops)
• i-views' build scripts

Below this line seems a nice spot to start a short list of requirements you have for such a project, feel free to add/edit:

• Smalltalk syntax (or a subset) for build scripts
• Be able to version build scripts in Store
• Handle multiple 'repositories' (directories with .pcl/.st files, Store)
• Build not only images but also drive ResHacker, compile modules in other languages, call Make/Ant/Scons/...
• Parallelized builds, perhaps distributed in the future.
• Support Continuous Integration.
• Run tests
• Drive image based COM Automation tools (generate IDL, generate .reg) as well as external tools (MIDL compiler)
• be callable by and can call Make/Ant/SCons/...

• Runtime images should be built from within a development image ("written out") without the need to snapshot and exit. This way development can resume while bugs are checked out in the runtime. Deploying a runtime basically should feel like some kind of "save image as..."
• See the technique of Image Gestation.
  In general BodyBuilder should support all 'compilation' techniques for images. At the moment that would be building up on a base image, stripping with RTP, and perhaps at a later date ImageGestation. --RH.
• Whether one wants to package a full product for shipping, or just a runtime image for testing should be easily configurable.
• Right, in the case of Make that is done by creating different rules.
• Inclusion and exclusion of packages, classes, methods, globals etc. should be configurable indepedently from Store packages/bundels, i.e. be programmatically useable to pick items across package bounds. This is especially useful when building product variants (i.e. a "Demo") that should exclude certain functionality for sure. Implementing this behavior with the package/bundle mechanism can be complicated because overrides are hardly maintainable.
• I don't consider different componentization part of BodyBuilder itself. Having said that we do have change files/sets available which allow us to script removals as well as additions using existing libraries. --RH
• RTP is nice, but we should get rid of it. Image "stripping" is prone to too many side effects and occasional issues. If saving runtime images from within a development image could be achieved, the rest of BodyBuilder is probably rather simple scripting.
• I insist on making BodyBuilder compatibile with all methods of image creation including stripping. --RH

Andre Schnoor andre_dot_schnoor_AT_web.de