Version 1 of Boost Build

Updated 2004-12-30 16:20:37 by skm

Using Boost Build with Tcl Projects

2004/12/30 sheila I'm working on a new build process for work and plan to use Boost.Build v2 to implement the builds. bjam v2 doesn't currently have a tcl toolset, so I'll be working on that. If it is of interest to the rest of the community, I can share notes.

Here are a few links to get started.

del.icio.us live bookmark: http://del.icio.us/tag/boost

Boost.Build v2 User Manual [L1 ]

The chapter on extending boost [L2 ] is most salient for me. I will be adding some tools to support tclapp and tclcompiler, or in fact, anything we want to customize with, following the recipes in this chapter. Boost.Build has the concepts of generators and scanners. It can automatically build dependency graphs for a project. I'm currently trying to grok how to map dependencies in tcl, since I'd like to be able to make a scanner class for my tcl project. A lot of it is done on the fly. I can follow pkIndex.tcl, tclIndex, look at package require, source... butthings on the fly -- such as running auto_mkindex at run time puzzle me for the time being.


2004/12/22 sheila Are there any pages in the wiki on configuration management, project management, formal reviews, build process, etc etc etc? I'm not sure which search strings to use, so I'd like a cheat sheet. Otherwise, I'll start one. I've found that just the right amount of structure in all of this, for a large project, contributes to productivity and stability; but when using tcl (or I suppose any scripting language) the process can get unweildy since the rate of change in tcl scripts is higher (at least, in my experience) than the rate of change in c code. So, I've been wondering how other people manage these things.

For example, for a project with a c code base, any changes whatsoever can undergo peer review without a big head ache, assuming you have the right process to speed things up, but for a tcl code base, does this hold? I've found it to be a big headache before. But, perhaps that was due to the stability of the code base compared to the stability of the other code base.