Re: [boost] Re: Why Jam?

From: Braden McDaniel (braden_at_[hidden])
Date: 2002-02-23 21:03:06

On Sat, 2002-02-23 at 13:33, David B. Held wrote:
> ----- Original Message -----
> From: "Braden McDaniel" <braden_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Friday, February 22, 2002 11:27 PM
> Subject: Re: [boost] Re: Why Jam?
> 
> 
> > On Fri, 2002-02-22 at 23:30, Chris Little wrote:
> > [...]
> > > Boost is an experiment in leading edge C++ design.  The goal isn't
> > > necessarily to create a library that integrates well into your unix
> centric
> > > view of software development.  In fact there isn't a required set of
> > > platforms that an implementor need to support.
> >
> > The success of this project will be measured to a large degree by the
> > size of its user base--like most any other project. This is about making
> > Boost usable. That's all.
> 
> Well, I'm not sure you understood what Chris said.  The project *isn't*
> about how to produce a library with the broadest possible user base.  As
> I understand it, the purpose is to create "prior use" cases for suggested
> language modifications.  To that end, a sufficient number of people will
> use Boost, easy or not, and help to establish how new idioms and concepts
> work in the real world.  I would thus conclude that the success of this
> project will be measured by what good and useful language features make
> it into the next standard because of a demonstration of prior art.  That can
> be accomplished without catering to the needs of every user (and seems
> to have done so just fine until now).  I think it's just a nice side effect
> that
> people like me get to use really powerful libraries boost::function,
> boost::bind,
> and boost::smart_ptr, and if I see the best features of these libraries in
> the next version of C++, I will feel that Boost has accomplished its goals,
> as probably will the maintainers and authors.

Apparently you do not understand that the size of a project's user base
is a reflection of its general utility.

> > > If you want to use Boost in one of your projects then I think that it is
> up
> > > to you to provide integration for your users.  It is not as if Boost
> makes
> > > any guarantees about binary or source compatibility (although as a
> > > community I would hope that we minimize the amount we break things
> > > while evolve them) so any project you make will have to bound to a
> > > particular Boost version anyways.
> >
> > This is par for the course for open source projects. It may be novel
> > from your perspective; it is not from mine.
> 
> To this extent, I see Boost as "more Open-Source than Open-Source".
> To put constraints on an Open-Source developer as to how many platforms
> should be supported, and how other things like installation should be
> handled really limits developers.  Some developers don't have every
> target platform to test on and write workarounds for.  Some just don't
> have the time to create a one-button-push install procedure.  If Boost
> were a singular effort like Apache or MySQL, it would make a lot more
> sense to provide things like sane install targets.  But Boost is much looser
> than traditional monolithic OSS projects.  In this regard, many OSS
> projects are more like closed-source software than Boost is.  Boost
> provides raw libraries with raw power, no promises or guarantees.  It
> is offered freely, by people who are very capable at producing some of
> the best code possible.  To expect each library author to maintain his/her
> library like it's a big team OSS project seems quite unfair to me.  It also
> seems selfish to expect that pro-autoconf constraints are more important
> than pro-Jam constraints.  As far as I can tell, this thread sounds like
> a Porsche dealership giving away free cars, and people complaining
> that the cars aren't driven to their doorstep.  It doesn't seem unreasonable
> at all to me to meet them halfway.

What's halfway? What is it you're arguing, exactly? Are you suggesting
that Boost should *not* accept an autotools build?

> > You say that like I was reluctant. That is a misrepresentation. When
> > this thread started, it was not clear that an autotools build would be
> > accepted into Boost even if it was offered. In fact, I think one could
> > reasonably conclude that it would be rejected based on threads prior to
> > this one. Fortunately, it now looks like an autotools build would be
> > accepted. That's all I've ever wanted.
> 
> >From what I observe, the "Boost process" is to *ask* whether a library
> or tools submission would be useful or welcome first, instead of telling
> people that they want and need it, and if they don't, they are closed-minded
> pig-headed greedy proprietary jerks with their heads in the sand.

Review my postings to this thread. From my perspective, this has never
been about a particular tool. It is about the need for an install
target. I have indicated that I would be just as happy with "jam
install" as "make install". But the Jam folks tell us that "jam install"
isn't likely to happen in the foreseeable future--which suggests to me
that it would be a lot of work even for the folks who are Jam experts.

"make install", OTOH, is relatively easy to set up ... with the
autotools.

To extend your analogy, providing software without a deployment strategy
is like giving someone a free car and telling them they have to make
their own wheels from scratch. If you're a closed source project, you
can just strip the car for parts and use them in the separate car you're
building. If you're an open source project, you wanted to use that free
car to tow the camper you're building, and the absence of wheels is a
real problem.

> > It may be self-satisfying to characterize the autotools crowd as a bunch
> > of complainers. But in doing so you ignore the "Let them eat Jam" policy
> > that led to this thread.
> 
> And to be honest, I think it's entirely the prerogative of those offering
> free
> bread to offer a Jam-only version.  If you want your bread toasted or
> pre-made into a sandwich, perhaps you should ask whether you are
> grateful for the bread, or feel you are just entitled to it.
> 
> > That's changed, and so on this much we agree: Let's move on. I'm
> > looking forward to seeing Timothy Shead's submission.
> 
> As am I.

I am confused: are you arguing that Boost should not accept an autotools
submission or not? If not, *what is your point*?

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