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
> > > > to tell my users to install Boost?
> > >
> > > This is pretty easy. You tell them to add -I ~/boost to the command
> > > :-)
> > 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
> 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.
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
> version of Boost (minus .jpg/.pdf/whatever files) against which
> Other projects will prefer not to include a copy of Boost.
> Either way, it's ./configure --with-boost[=location], with the
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk