Subject: Re: [boost] Boost Evolution
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-10-08 16:29:29
> Hi Robert,
>> If its a useful
>> which is shared by several libraries, it should be in something like:
>> "unreviewed". And of course these should have thier test and
>> documenations in the corresponding "lib" subdirectory.
> I disagree here. If is is useful to others it should be proposed for
> review if it can not be integrated in an existing library. Otherwise
> it is up to the author that is using the detail part to maintain it,
> at least respect to the user of her/his library.
In detail, one finds some things like: utf8, lightweight test, among
other things. In fact I use both of test so I know they are used
by multiple libraries. So this raises the question as to where
they should go. They are in fact unreviewed and they are not
an implementation detail of only one library. They're not going
away. The main thing that bothers me is that there is no
place for their documentation, tests, etc. 'utility" would be fine
except for the fact that they are unreviewed - so that's why
I picked "unreviewed.
> Why do we need to install part of Boost.
As boost get's bigger and bigger, the probablilty of failure to
install and pass tests gets larger and larger. So if someone wants
to use just one library to start he has to do the whole thing. If
he could do it one are a few libraries at at time it would be
much easier to ease into boost.
Also, there are many platforms (embedded and ?) which could
not run all of boost. If one has one of those, he has to install
all the libraries and then read and discard all the failures -
a time consuming and confidence shaking excercise. I would
expect the in the future one would be needing one component
- say shared_ptr, and just install that. just installing that (and
it's dependents) would take probably only a minute - maybe
two if one ran the tests and the user would be right where he
needs to be. Also, one would not have any accidental dependcies
on a bunch of other code. There a lot's of reasons to make
>Boost is a whole
It is now. That's what I believe will have to change, My view is
that it's becoming an obstacle to growth and usablility because
installation, testing, maintenance and deployment are not scalable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk