Boost.Build v2 User Manual [1]The chapter on extending boost [2] 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... but things on the fly -- such as running auto_mkindex at run time puzzle me for the time being.Perhaps I have to use an artificial method for this, but I'd hate to do that. Other people would have to adopt in order for my jam file to be useful for others.bjam is powerful enough that I could probably have a tcl script to do the auto_mkindex or pkgIndex to be used in a scanner... must continue to brain storm on this.I've been thinking about writing a scanner for the tclapp tool file that will use project files to determine dependencies. this doesn't always work, since people can use source statements in their files. Commands like that could refer to files not referred to in the project file. messy.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 unwieldy 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.clarifying old note: 2004/12/30 More thoughts. Ideally I'd like to follow some of the SW-CMM model (see [3]). Jargon aside, there are some useful ideas here. I've worked in a place where we followed a process based on this, and it mostly increased productivity. Naturally, there's a range where too much process is a burden, but so is not enough.
TV I guess it would have to be a pretty big project to do all the extra effort. The above link gives me the creeps like when thinking about scientific innovations would come from let us say European civil servants leading the way... I've been thinking about bwise for dependency graphs (which is possible), which is however also what make does, but with bit hard to parse syntax for general use I guess. The translation part to a specific compiler type is interesting, but probably could be one very usable function with general options and target compiler type in and the right command line out.
