Sorry my link wasn't specific enough. The paper at the other end of this link describes how and why the X Windows development utilizes IMAKE. Skip straight to section 2.

DA> Someone else contacted me by private email and suggested using CONS
DA> (http://www.baldmt.com/cons-faq/current.html). In fact, this person seems to
DA> have made substantial progress already setting up a build/test system for

I took a really quick look at CONS. My 1st impression is that it is immature. I say that due to the kind of problems I see in the Change Log for the development version. I also don't see anything indicating "industrial level" experience described. I know IMAKE will work because of the projects that have been successful with it. Of course, if someone has already done some groundwork it is certainly worth looking more deeply than my 10 minute evaluation. In the global scheme of things, some people might be put off if they have to learn a new make system, although it would still be an improvement in the current state of affairs. When I downloaded Boost, I found myself hacking Makefiles to try out parts I was interested in....

DA> This appeals deeply to me because I find make very difficult and capricious DA> to use,especially as systems become larger. I do wish that cons were Python-DA> based rather than Perl-based, but so it goes ;).

I agree with you about Make in general. It really doesn't scale. IMAKE makes things livable. On the large project I mentioned before, we didn't go to IMAKE because of portability, we did it because we wanted to be able to build the whole thing with a push of a button. If everyone was messing with their own Makefile strategies it wasn't going to work. At the same time, we didn't want a bunch of people developing Makefiles for a living. IMAKE was a good compromise because it was easy for developers to add new code into the make system with minimal hassle and it allowed us to generate consistent project-wide make files.

I actually like the idea of a Perl based system since Perl is freely and easily available on almost all platforms. I personally have Perl installed on all my Windoze systems because I find it very handy....

> 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

DA> People have raised CPPUnit on this list before. As I remember, the group DA> was generally unimpressed. I admit I've never looked at it myself.

Well, I wasn't overwhelmed either (in fact I'm still trying to figure out a few things), but we went for it since it seems to be reasonably clean, it doesn't require additional tools / languages, it seems to have strong backing by a reasonably large community of programmers, and it is better than starting from scratch.

DA> At my "real job", we're using my Python wrapping system (py_cpp in the

DA> vault) to quickly put Python APIs on our C++ libraries, and writing

I am a big fan of the recent crop of scripting languages. The interactivity and development speed without having to a compile cycle after every change really makes life better. I have not used Python, but I have used an approach similar to what you are doing with Perl on a previous project. It worked fine, we just started way too late. The big drawback is the need for people to learn another language, install another language, etc. If people are using or contributing to Boost then they are obviously at least part way up the C++ learning curve. I suppose the counter argument is that I suspect that most of the people developing stuff for Boost can likely digest a new language in a few hours of study.