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
[pdimov_at_webserver pdimov]$ wget -nv
811288] -> "boost_1_27_0.tar.gz" 
[pdimov_at_webserver pdimov]$ tar zxf boost_1_27_0.tar.gz
[pdimov_at_webserver pdimov]$ ls -l boost_1_27_0
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
> > 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk