Re: [boost] boost organization and installation

From: Noel Yap (yap_noel_at_[hidden])
Date: 2002-05-02 06:50:38

--- David Abrahams <david.abrahams_at_[hidden]> wrote:
> 
> ----- 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
> > questions.
> >
> > I think distributing boost in pieces
> 
> Interesting idea.
> 
> > would increase stability
> 
> How?
> 
> > (since newbies to Jam would quite easily
> > know what hasn't built),
> 
> How would they know? And how would knowing increase
> stability?

Because, for example, if they download only concept
checking, and it doesn't build, then it's obvious that
that's is what's not building regardless of how well
they know Jam.

Currently, Boost is as strong as its weakest piece --
if part of it doesn't build, all of it is broken.  If
it's in pieces, each piece will be as strong as it
needs to be.

> > ease configuration management
> > of software that uses boost (since it's easier to
> know
> > what uses what has changed),
> 
> Maybe. Hard to say.

I have stated my opinion as a CM.  I would like to
hear from other CMs on this point.

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

I'll assume for the moment there's a good reason this
is.  However, if the libraries were distributed
separately, its developers would more easily create an
aam solution as well.  As it stands, this is not
encouraged since all users of Boost will read Boost's
build and install directions.  If each library had its
own build system, they can refer to Boost's Jam
instructions as well as supply aam (or other)
solutions.

> 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."
>
(http://aspn.activestate.com/ASPN/Mail/Message/boost/1185890)
> 
> 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.

I've heard that the aam learning curve is not that
steep (although this may or may not assume Unix
experience).

> > So, my question is,
> > "Why is boost distributed as one whole library
> rather
> > than distributing each piece separately (as
> Jakarta
> > does)?"
> 
> I think this may answer your questions:
> http://www.boost.org/libs/hdr_depend.html

This tells me that there is a dependency hierarchy
within boost.  Such hierarchies are typically
addressed through documentation.

Now that this hierarchy is more real to me, I've come
to the conclusion that a reorg would also entail at
least one unique namespace per library.  I think this
is a Good Thing (tm) since, from what it looks like,
each library is developed by different sets of
developers; separate namespaces will decrease the risk
of name clashes.

> > 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).
> 
> We have a tool somewhere that can generate the
> header dependency page
> mentioned above. Not sure where, though... ;-(

But if each library were distributed separately, such
a tool wouldn't be necessary (at least for the users
of the library).  Don't you think that such
implementation details shouldn't have to involve the
users?

> > IMHO, at the very least, I should expect boost to
> > build OOTB without any errors.
> 
> On every compiler and OS? Unrealistic.

This is more of a reason to partition boost.  As I
said (or implied) earlier, currently Boost's
development and build processes are as strong as its
weakest component.      Since Boost's pieces (and
therefore Boost itself) is very much in flux, there is
a strong chance that it will not build at any one
time.  This chance increases the more projects are
brought under Boost.

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

My bad.  I was trying so hard to stay away from the
aam vs Jam discussion.

Noel 

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