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> wa
s 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.
Jeff