From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-01 17:06:45
----- Original Message -----
From: "Noel Yap" <yap_noel_at_[hidden]>
> Please pardon my ignorance. Being new to boost, I
> have preconceived notions of how free software
> "should" be. I will try not to let them taint my
> I think distributing boost in pieces
> would increase stability
> (since newbies to Jam would quite easily
> know what hasn't built),
How would they know? And how would knowing increase stability?
> ease configuration management
> of software that uses boost (since it's easier to know
> what uses what has changed),
Maybe. Hard to say.
> and decrease the traffic
> about autoconf/automake/make vs Jam (since those
> projects that need to use Jam can do so while the rest
> can use autoconf/automake/make).
All projects with built components need to use Jam.
Why? In part for the same reasons you say "I'd volunteer but learning
how to develop with aam is still on my to do list."
It's a very steep learning curve for developers. Unfortunately,
Boost.Build has same problem for users... but though steep, it's short,
and getting shallower.
> So, my question is,
> "Why is boost distributed as one whole library rather
> than distributing each piece separately (as Jakarta
I think this may answer your questions:
> My particular situation is that I want to use only the
> concept-checking portion of boost but I feel I'm
> forced to install everything since I'm not sure if the
> portion I want is dependent on any other portion
> (without going through the implementation which, I
> think, is counter-productive to what concept-checking
We have a tool somewhere that can generate the header dependency page
mentioned above. Not sure where, though... ;-(
> IMHO, at the very least, I should expect boost to
> build OOTB without any errors.
On every compiler and OS? Unrealistic.
> If any portion of it
> doesn't, then the particular version that I have,
> boost-1.27.0, shouldn't be labeled "stable". If,
> however, it's not building due to my particular
> environment, then I think this is a reason to
> investigate using autoconf/automake/make since I've
> had no problems building and installing the myriad
> software that use them.
Hardly any of that software pushes the boundaries of C++ the way boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk