Re: [boost] boost organization and installation

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-01 16:56:41

----- Original Message -----
From: "Noel Yap" <yap_noel_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, May 01, 2002 4:26 PM
Subject: [boost] boost organization and installation

> 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
> questions.
>
> I think distributing boost in pieces would increase
> stability (since newbies to Jam would quite easily
> know what hasn't built), ease configuration management
> of software that uses boost (since it's easier to know
> what uses what has changed), 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).  So, my question is,
> "Why is boost distributed as one whole library rather
> than distributing each piece separately (as Jakarta
> does)?"

Well, from my stand point, seperating the libraries will actually make
things more difficult for the Boost developers.  For instance, Boost.Threads
currently relies on Boost.Function, and shortly will also use Boost.Bind.
Seperating the libraries for distribution purposes will just complicate the
distribution of Boost.Threads for this reason.

> 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
> encourages).

Seperating the libraries won't fix this for you.

> IMHO, at the very least, I should expect boost to
> build OOTB without any errors.  If any portion of it
> doesn't, then the particular version that I have,
> boost-1.27.0, shouldn't be labeled "stable".

At least one of the "unstable" portions of 1.27.0 was Boost.Threads.  The
problem was a simple typo resulting in an extern "C" block not being closed.
As the developer, at the time the only box I had available for testing on
was a Win32 box, where tests passed for most of the compilers I had
available (there's still an outstanding issue with gcc which I have yet to
resolve).  So as far as I could tell at the time, it was stable.  So, the
problem was simply that Boost doesn't have a way to determine stability for
multiple platforms.  And it's not an easy thing to insure, because Boost
libraries tend to push compilers to the breaking point.  Not all compilers
will be able to compile any given Boost library.  So insuring stability
can't mean that all libraries compile on all platforms.  Then there are
issues for such things as Boost.Python that rely on things outside of Boost.
If you don't have python installed on your machine, Boost.Python won't
compile, but that's not an indication of unstability.  So, ignoring the fact
that a few things slipped by in 1.27.0 that shouldn't have, a "build OOTB"
criteria can't be used for measuring stability any way.

>  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.

aam doesn't insure you can "build OOTB".  For instance, aam couldn't cause
Boost.Python to compile for you if you don't have the required python
installation.  At best it reduces a number of error messages to a single
one.

>  I'm very surprised that noone
> has yet (to the best of my knowledge) attempted to use
> the more standard tools for boost.

Please read past threads on this topic.  aam is *not* standard for anything
but POSIX environments.  In any event, the Boost membership has stated again
and again that they'd welcome an aam contribution, but we can *NOT* mandate
aam as a requirement for our libraries.

>  If I have time,
> I'll try to do this at least for the portion(s) that I
> want to use.  Meanwhile, if I am mistaken and someone
> has attempted to do this, can they step forward and
> brief me on their findings?

Again, search the archives for this information.

Bill Kempf