RE: [boost] build system?

From: Jeff Garland (jeff_at_[hidden])
Date: 2000-07-22 18:14:54

  David Abrahams wrote:

  JG > Makefiles for all the variations.  You can find info on Imake at
  JG > http://www.primate.wisc.edu/software/imake-stuff/.

  DA> I went there but didn't find any readily accessible information on
  DA> what imake

  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.

  Jeff