From: David Abrahams (abrahams_at_[hidden])
Date: 2000-07-22 15:54:57
From: Jeff Garland
> As it turns out, I have been researching this issue recently for a C++
> I am working on (some related research for a smart pointer implementation
> me to run across Boost and start paying attention to what you' all are up
> :-). Anyway, one of the key goals for the project is cross-platform (NT
> various Unix/Linux flavors) and cross-compiler (probably g++ and vcc)
> compatibility. Of course, we also want a fully automated build and test
> system so that we can rapidly detect and fix any changes which create
> issues. Unfortunately, none of this is really easy or "lightweight".
I don't expect it to be lightweight. One can only hope for some ease-of-use,
though. It's hard to achieve if make is involved :(
> So far, it looks like the best answer incorporates 2 "tools". For the
> part, use IMake to simplify makefile creation and factor out vendor and
> platform specific configurations. In a nutshell, Imake uses macros and
> template files to allow you to write one file (the IMakefile) and generate
> Makefiles for all the variations. You can find info on Imake at
I went there but didn't find any readily accessible information on what
does or how it is used. Is there any way to find out about it other than
that O'Reilly book?
> I have used Imake on a
> rather large C++ project (more than 200 people), and it worked quite
> once it was set up. The other main alternative I have seen is to just
> maintain by hand Makefiles for every platform / compiler. This is what
> to have been done on ACE, and I hear it makes it really difficult to add
> files, remove files, reorganize directories, etc.
Someone else contacted me by private email and suggested using CONS
(http://www.baldmt.com/cons-faq/current.html). In fact, this person seems to
have made substantial progress already setting up a build/test system for
boost (I will not name names until authorized by the person in question).
appeals deeply to me because I find make very difficult and capricious to
especially as systems become larger. I do wish that cons were Python-based
rather than Perl-based, but so it goes ;).
> The other part of the equation is to automate testing using CppUnit from
> http://www.xprogramming.com/. CPPUnit is derived from work done by Kent
> on testing frameworks which spawned. Of course CPPUnit is already
> along compiler and platform lines as you can see from the download page.
> However, if you dump the GUI, the framework is trivial to port. Anyway,
> idea is that a single command can test everything and report the results
> the form of pass/fail statistics and diagnostic pointers for any failures.
> Again, as an example, while ACE doesn't use CppUnit, it does have a
> consistently written set of tests which allow rapid validation.
People have raised CPPUnit on this list before. As I remember, the group was
generally unimpressed. I admit I've never looked at it myself.
At my "real job", we're using my Python wrapping system (py_cpp in the
quickly put Python APIs on our C++ libraries, and writing test scripts in
Python. This allows us to play with our components and develop tests
interactively in the Python interpreter. Also, we can use the Python doctest
module which allows us to copy/paste interactive Python sessions into a
module's documentation strings. The testing cycle looks like this:
1. Add C++ functionality
2. Extend the python wrapper if neccessary
3. Fire up the Python interpreter. Import the wrapped library module and
few tests by hand.
4. If you like the results, copy that fragment of the interactive session
docstring. Now the results will be confirmed whenever the regression/unit
tests are run.
This approach is attractive in many ways, but also has two downsides that I
1. There is an extra layer of python-wrapping "stuff" that could obscure
of the material we're really concerned with
2. You can't wrap a template in Python, exactly. All wrapped Python classes
refer to specific instantiations of a template. Not a huge deal, I think,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk