Re: [boost] boost organization and installation

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-02 07:15:06

----- Original Message -----
From: "Noel Yap" <yap_noel_at_[hidden]>

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

And how would that increase stability?

> Currently, Boost is as strong as its weakest piece --
> if part of it doesn't build, all of it is broken.

That's just wrong. Have you looked at the compiler status tables
(http://www.boost.org/status/compiler_status.html)?

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

Yes, and if you won't search the archives for rationale because of the
"high S/N ratio", I guess you'll stay in the dark about those reasons.

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

That's already permitted.

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

We also have reasons for not doing that.

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

Fabulous! I presume you are planning to reorganize and test the
libraries in this configuration without interrupting development or
breaking backward compatibility for users...

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

They don't now.

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

You keep saying that, but it doesn't hold water.

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

That hasn't been the case in practice (and you'd need to define what you
mean by "building", since most of the libraries don't need to be built
at all). Not all parts of boost are interdependent. If Boost.Python
doesn't build on some platform, it doesn't prevent the threads or regex
libs from building.

-Dave