Re: [boost] boost organization and installation

From: Noel Yap (yap_noel_at_[hidden])
Date: 2002-05-02 10:56:19

--- David Abrahams <david.abrahams_at_[hidden]> wrote:
> > 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?

I apologize for not being clear enough on this. 
Currently, if one part of Boost doesn't build, then,
at least to the user (and especially to a
configuration and quality manager), all of it doesn't
build.  IOW, Boost is as stable as its most instable
piece.

If it were distributed as separate projects, each
project's stability will depend only on its own
stability and that of its dependencies.  In fact, the
stability of its dependencies can be controlled by the
user since they control which version of the
dependencies are being used.  If there are version
dependencies, then they need to be documented.

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

What I said is completely true for a configuration and
quality manager.  It is not possible to bless a whole
release of a product if part of it doesn't build.  I
would like to hear from other CM's on this topic.

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

It may be permitted, but the current organisation
doesn't make it amenable to such things.  For example,
where should the aam files for concept_check go?

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

Can you point me to the document that state the
rationales, please?

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

No.  Backwards compatibility will no doubt be broken,
but I didn't see anything in the requirements stating
anything abuot backwards compatibility.

I also don't see why such a move can't be done
incrementally (eg one library at a time).

In my case, I'll work on getting Concept Checking
separated first.  I'll probably do it using Jam so as
not to introduce anything new in this regard.

In the end, my goal is have one tarballed file with
only the stuff necessary for Concept Checking.

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

You're right, they don't.

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

Can you explain your statement, please?  I think you
or someone else on this thread said that 1.27.0 was
one of the worst releases.  From what I've seen, this
is due to broken builds in only some of the
components.  The part that I want to use is fine but
will not get passed a CM/QM blessing since the whole
package doesn't build correctly.

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

But, the way it stands now, if I wear my CM hat Boost
as a package needs to be built and installed as one.

> Not all parts of boost are interdependent.

This is more of a reason not to package everything as
one.

> If Boost.Python
> doesn't build on some platform, it doesn't prevent
> the threads or regex
> libs from building.

That's correct, but it does prevent the entire package
from building correctly.  I think you and I disagree
on this part.  A CM will never say that a partial
build of a product is good to use in production. 
Would you agree?

Noel

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