Re: Why Jam?

From: braden_mcdaniel (braden_at_[hidden])
Date: 2002-02-25 17:36:40

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "Braden McDaniel" <braden_at_e...>
> > On Mon, 2002-02-25 at 06:36, Peter Dimov wrote:
> > > From: "Braden McDaniel" <braden_at_e...>
> > > * Installation
> > >
> > > >         * If my open source project depends on Boost, how am I
> supposed
> > > >           to tell my users to install Boost?
> > >
> > > This is pretty easy. You tell them to add -I ~/boost to the command
> line.
> > > :-)
> >
> > Weak.
> 
> 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.

> > And this does not facilitate the creation of binary packages for
> > boost the way a "make install" does. RPMs are a lot easier to make and
> > maintain if a package has a sane "make install". Ideally, Boost binary
> > packages would be included with my users' OS distributions. That won't
> > happen overnight, but "make install" is a way of oiling the gears.
> 
> I don't see why it's necessary to have a 'make install' in order to
make a
> boost RPM, but it must be my ignorance.

It's not "necessary". I didn't say it was necessary. I said it makes
it much easier.

> > There needs to be a "standard" place that Boost lives on systems. Only
> > users who install Boost to a nonstandard prefix should have to worry
> > about explicitly chasing it down every time they build a project that
> > depends on it.
> 
> I don't remember anybody arguing against that. Users are free to unpack
> boost in whatever place is considered standard on their platform.

<sigh>

This is getting old. Unpack != installation!

> > > Either that, or _your_ configure script does that automatically.
> > > (configure --with-boost=~/boost, defaults to
> > > $(my_open_src_project_root)/include/boost, presumably.)
> >
> > So you're suggesting it's reasonable for me to include a copy of Boost
> > in my project's distribution? Try again.
> 
> Yes, I am suggesting exactly that. Some projects will include a copy
of the
> version of Boost (minus .jpg/.pdf/whatever files) against which
they've been
> tested.
> 
> Other projects will prefer not to include a copy of Boost.
> 
> 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.

> > It bloats my project's
> > distribution and, more importantly, it's a maintenance nightmare.
> 
> 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.

> Anyway, it's your choice.

Right now, there's not much of a choice.

Braden