From: Noel Yap (yap_noel_at_[hidden])
Date: 2002-05-02 07:47:17
--- David Abrahams <david.abrahams_at_[hidden]> wrote:
> ----- Original Message -----
> From: "Noel Yap" <yap_noel_at_[hidden]>
> > So this is a process problem. If there existed
> > where nightly builds occured before things are
> > "stable", this problem wouldn't occur.
> That's not all it takes, but it would help. We are
> trying to develop a
> more reliable release process, but unfortunately
> haven't released
> anything since 1.27, which IMO was one of our worst
Lucky mean, then, since that's the one I downloaded.
I might have a worse picture of the development
process in mind because of it. I'll see how 1.26 is.
At least we're on the same page on this one -- this is
a process problem. It's great you're working on
I think once the release process is improved, it will
diminish, but not eliminate, my stability concerns --
there's still many pieces that doesn't concern me that
could introduce instability.
This segues into my configuration management concern
which, I think, I've elaborated enough.
> > In any case, all of boost is now dependent on
> > since at least one part of it depends on Python.
> That's just false.
Why do you say that? If Boost depends on
Boost.Python, and Boost.Python depends on Python, then
Boost depends on Python (ie dependency is transitive).
Would you agree that dependency is transitive?
> > If things were distributed separately, only
> > would be dependent on Python. Those that don't
> > Python will either install Python, or not install
> > Boost.Python.
> You don't need a separate distribution to get that.
> The current CVS
> state skips building the Python library if Python
> isn't installed or
But why download it at all?
Also, what if Python is really installed but the build
can't see it?
Why complicate the entire Boost build due to a
dependence of only one of its components? Will this
scale if more components have more dependencies? Will
it scale as well as if each library took care of their
> > > aam doesn't insure you can "build OOTB". For
> > > instance, aam couldn't cause
> > > Boost.Python to compile for you if you don't
> > > the required python
> > > installation. At best it reduces a number of
> > > messages to a single
> > > one.
> > I think aam could check for this dependency and
> > out a friendly error message. If Boost.Python
> > distributed separately, only its build would
> > Python.
> Probably. OTOH, that's the way Boost.Build works
> > > 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
> > > 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.
> Why don't you figure out how to do that, create
> separate distributions,
> and post some kind of example for us with
> instructions for library
> developers to keep these separate distributions in
> good health? Then we
> can evaluate your claim.
OK. I'll start with the Concept Checking library.
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk