Re: [boost] Re: Why Jam?

From: Braden McDaniel (braden_at_[hidden])
Date: 2002-02-26 09:23:05

On Tue, 2002-02-26 at 06:48, Peter Dimov wrote:
> From: "braden_mcdaniel" <braden_at_[hidden]>
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > > Weak or not, it works.
> >
> > Nope. As other have mentioned, it fails to set permissions, and it
> > fails to take care of the bookkeeping involved in installing a library.
> 
> The context I had in mind is "installing the parts of Boost that don't
> require compilation."

Why did you have that in mind? The problem is certainly of a broader
scope. A solution that does not solve the issues with installing shared
libraries is no solution at all.

> > > Either way, it's ./configure --with-boost[=location], with the
> > appropriate
> > > default.
> >
> > It's an extremely inadequate suggestion, for all the reasons I and
> > others have enumerated. It is not productive to keep reiterating this
> > suggestion without offering solutions to the problems we have enumerated.
> 
> You are somewhat missing the point. I don't offer suggestions or solutions.
> I ask questions: "why is ./configure --with-boost=... inadequate?" in order
> to identify the problems.

Such a solution is fine if the user has installed Boost to a nonstandard
location. But there is currently no means of installing Boost to *any*
location.

> _If_ you have a specific problem with Boost.Bind, or Boost.SmartPtr, _then_
> I will have to start offering solutions. ;-)

You seem to content to try to focus this discussion on Boost libraries
that consist only of headers. The problem is bigger than that, and so is
this discussion.

> > > Not including boost may turn out to be a maintenance nightmare as well.
> > > (Although we try hard to ensure that releases are backward
> > compatible, slips
> > > do happen.)
> >
> > It'll work just fine. I can solve this problem using autoconf.
> 
> OK, I've no problem with that. Other open source projects have decided to
> include some of their critical dependencies in the distribution. I assumed
> that they have reasons to do so.
> 
> All this is getting nowhere fast, so here goes another couple of questions:
> 
> * My estimate is that an autoconf/automake expert can produce the necessary
> infrastructure that will auto-enable Boost in less time than we spent on
> this discussion. Is this correct?

Yes.

> * Given the above infrastructure, what will the average Boost developer do
> in order to support it?

If we take "average Boost developer" to mean one who does not want to
mess with the autotools build, s/he would mail an autotools build person
whenever there were changes that required modification of the Jam build.

For the persons in charge of making Boost releases, a few steps would be
added to the release checklist: update libtool library version numbers,
and change the Boost version number in configure.ac.

-- 
Braden McDaniel                           e-mail: <braden_at_[hidden]>
<http://endoframe.com>                    Jabber: <braden_at_[hidden]>