Re: [boost] boost organization and installation

From: Noel Yap (yap_noel_at_[hidden])
Date: 2002-05-01 17:17:29

--- "William E. Kempf" <williamkempf_at_[hidden]>
wrote:
> 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.

The usual way to deal with interdependence is through
documentation of that interdependence.

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

Separating out the libraries would allow me to install
easily only the parts that I want.  It will solve the
problem.

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

So this is a process problem.  If there existed boxes
where nightly builds occured before things are labeled
"stable", this problem wouldn't occur.

In any case, all of boost is now dependent on Python
since at least one part of it depends on Python.  If
things were distributed separately, only Boost.Python
would be dependent on Python.  Those that don't have
Python will either install Python, or not install
Boost.Python.

> 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 think aam could check for this dependency and spit
out a friendly error message.  If Boost.Python were
distributed separately, only its build would require
Python.

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

This sort of contribution would be easier satisfied if
the libraries were separately distributed.

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

Unfortunately, there's a low signal-to-noise ratio in
the archives.  I don't want to rehash the arguments of
aam vs Jam, but I do think separating out the dists
would ease the debate.

Noel

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com