Re: [boost] build system?

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++
project
> I am working on (some related research for a smart pointer implementation
led
> me to run across Boost and start paying attention to what you' all are up
to
> :-).  Anyway, one of the key goals for the project is cross-platform (NT
and
> 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
porting
> 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
build
> 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
> http://www.primate.wisc.edu/software/imake-stuff/.

I went there but didn't find any readily accessible information on what
imake
does or how it is used. Is there any way to find out about it other than
buying
that O'Reilly book?

> I have used Imake on a
> rather large C++ project (more than 200 people), and it worked quite
nicely
> 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
seems
> 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).
This
appeals deeply to me because I find make very difficult and capricious to
use,
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
Beck
> on testing frameworks which spawned.  Of course CPPUnit is already
fractured
> 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,
the
> idea is that a single command can test everything and report the results
in
> 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
vault) to
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
Python
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
write a
   few tests by hand.

4. If you like the results, copy that fragment of the interactive session
into a
   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
can
see:

1. There is an extra layer of python-wrapping "stuff" that could obscure
testing
   of the material we're really concerned with

2. You can't wrap a template in Python, exactly. All wrapped Python classes
must
   refer to specific instantiations of a template. Not a huge deal, I think,
but
   worth mentioning.

Thoughts?
Dave