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?