Software Review of Visual Build Pro 6 by Kinook Software

Why do I Need a Build System?

If you develop software for a living, you need to have a reliable and consistent way of producing it. Oh sure, just dig out the compiler and make an executable then load Installshield or your favourite installer. Then you run the installation through your regression test software and if it passes, upload it to a website or email to a client. However this isn't very professional so...

A thrown together system isn't very professional and depends upon one person who may be absent. It's how many companies start but once you get more than one developer, and start using version control systems (VCS) then you need to think about automating the process. Ideally you want an end to end system that pulls files out of the VCS, builds a complete installation, runs the regression test and reports any problems. That's the Holy Grail of development and achievable with Visual Build Pro 6.

What are the Alternatives?

Alternatives to build systems like Visual Build Pro 6 include batch file systems which tend to be error prone, and not easy to maintain. I've been converting from a build system that used batch files: These suffered from non existent error handling, were a pain to debug and there was no easy way to stop at an error and then continue. This one had evolved over a 12 year period and a run took several hours to complete- from fetching files from a networked version control system, compiling all source code, copying built executables and finally creating an installation. If any part of this process failed then it usually had to be rerun.

Visual Build Pro 6 (VBP) is an application provided in both GUI and console versions that powers a complete build process. Typically you use the GUI version with it's IDE to build and test build scripts then use the console version in the build.

These aren't scripts in the conventional sense of the word but a series of steps, each a procedure that does something. If steps provide the code to run the build process, the C style macros are actually the variables in the process and correspond roughly to the %a..%z parameters you get with batch files. These can be defined globally or per project and can be nested up to 20 levels deep. Much of the power of VBP stems from this as you can switch folders, drives, builds etc by just changing a single macro value.

VERSION is 15
RELEASE is R%VERSION% (Eg R15)
EXE is APP%RELEASE% ( APPR15 )
RELDRIVE is C:
RELDIR is %RELDRIVE%\%EXE% (c:\APPR15 )

By changing VERSION to say 16, every macro is automatically updated so RELDIR becomes c:\APPR16 and so on. Some of the compiler parameters are very long and difficult to edit in batch files. As macros it is a lot easier.

There are approximately 100 steps provided with VBP. These cover nearly every task you could think of, from running programs, scripts, setting macro values, compiling with Borland and Microsoft compilers, manipulating files by copy, delete etc and zipping/unzipping. It can also create installations using 13 different installers (You need to have the Installation software installed- that isn't included!). Other steps include registering type libraries, generating resource files, installing services, writing registry keys, internet services such as FTP, HTTP, mail, Telnet and lots more.

Each step can be run conditionally- depending on whether a macro is defined/undefined, or contains/doesn't contain a particular string etc and on the existence or absence of folders or files. There is no need to rerun a step if it has built before this. Steps can also be rerun while the condition remains true.

Output from steps can be optionally logged and step failure can trigger other steps, eg send an email. Steps can also be built in projects and run from another step. Unusually for a system so powerful, it is very intuitive and easy to setup.

It's important to specify compiler parameter strings such as include files as macros. On a big project you find the same compiler options are used many times, so cutting and pasting the compiler steps made it very quick to define.

Each step name in a build can be renamed so you end up with very descriptive build definitions. A particular boon is the mouse flyover over macros which expands them and shows their value in a tool tip. Such a simple feature but one that makes designing a build considerably easier.

Version Control Systems

There are steps to handle six Version Control Systems including CVS and Subversion. One of the first builds I wrote, created a folder (if not present), pulled a few hundred files from a Subversion server then ran a compiler to build the whole thing. Before compiling it ran a resource compiler to generate resource files needed for the compile. After successfully compiling it copied the executables to a remote folder. Other steps used assigned values to macros and changed folders. Over half of the steps in the build were change folder, assign macro values. With existing batch files, each step more or less corresponds to one instruction.