Re: [boost] Re: Why Jam?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-26 06:48:10

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

[pdimov_at_webserver pdimov]$ wget -nv
http://boost.sourceforge.net/release/boost_
1_27_0.tar.gz
13:29:53 URL:http://boost.sourceforge.net/release/boost_1_27_0.tar.gz
[3811288/3
811288] -> "boost_1_27_0.tar.gz" [1]

[pdimov_at_webserver pdimov]$ tar zxf boost_1_27_0.tar.gz

[pdimov_at_webserver pdimov]$ ls -l boost_1_27_0
total 60
drwxr-xr-x   21 pdimov   admin        4096 Feb  7 17:36 boost
-rw-r--r--    1 pdimov   admin        8819 Feb  7 17:25 c++boost.gif
[...]

Permissions look OK to me.

I - obviously - agree that this won't build or install any shared libraries.
My point is that open source projects that don't use Boost.Python,
Boost.Threads, or Boost.Regex, do not _require_ an install system. It would
be convenient, of course.

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

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

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

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