During the last several years, our flagship product, kbmMW, have been supporting more and more IDE's and versions, and it has also undergone a facelift in the sense that multiple editions were made available.

kbmMW currently consists of 2 packages (one runtime and one designtime) for each IDE for each edition. Each of those packages consists of one or two files. As kbmMW currently supports 10 different IDE's/variants (D5, D6, D7, D2005 Win32, D2005 .Net, D2006 Win32, D2006 .Net, D2007 Win32, C++ Builder 6, Kylix 3), and there are (or have been) 6 different flavours of kbmMW (OpenSource, Std, Pro, ProPlus, Ent, CodeGear), simple math makes the number of files to update each time a source file is renamed, deleted or added quite staggering. Its currently totalling around 100 files that must be updated!

That was starting to get REALLY boring to do, not to say time consuming and error prone. Automation must be the name of the day!

Hence we had to invest some time in a new product called kbmProject, which essentially is an advanced project file generator using scriptable templates.

In it we define:

• Units - which defines all the units that we know of for kbmMW as a whole. The unit definitions can also include information about forms/datamodules etc.
• Requirements - which define all the possible requirements that we know of for kbmMW as a whole.
• Projects - which we use for defining editions and what subset of the Units definition and Requirements they should contain.
• Templates - which defines the overall layout of the files. The templates can contain scripts and take advantage of variables/parameters defined on a job, project, template group, template, unit and snippet level etc.
• Template groups - which we use for defining groups of templates ... doh...
• Jobs - which is a combination of a Project and a Template Group

In addition we can define:

• Snippets - which essentially are small reusable code/data pieces that can be referenced from within a template
• Conditions - which for example can be used to indicate if a specific unit or requirement should be part of a specific package under some given conditions

When it all has been hooked up correctly, its as simple as clicking a Generate all button and all the relevant package files are generated automatically.

Quite neat!

This is a screenshot of the units pane... notice the raw unpolished look :)... its a good indication for this being a tool for toolers :)

And the following is a screenshot showing the templates and template groups.

As can be seen, the currently selected template simply contains a reference to the snippet BPK_kbmMW_Designtime. It could have contained alot more if needed, but I decided that I preferred the snippets to contain all the info as it would then be easily reusable.

So lets checkout the snippet then....

The snippet can be opened in a fullscreen editor to make it easier to read/edit.

Some places in this snippet there are references to either parameters or other snippets. The {%$=...} syntax references a parameter, and the {%$@....} references another snippet that will be inserted at that place.

The parameters can be defined on almost all elements in kbmProject. They are searched in a specific order to for example ensure that the parameter ANAME on the unit level takes precedence over ANAME (if defined) on job level etc.

The following show the scripted snippet SpaceLibsFroBpkPackage.

Anyway this was just to show you some of the extra tools we need to maintain continued development of kbmMW.

Kim/C4D