Boost logo

Boost :

From: braden_mcdaniel (braden_at_[hidden])
Date: 2002-02-28 15:20:36


--- In boost_at_y..., Rene Rivera <grafik666_at_r...> wrote:
> On 2002-02-28 at 03:46 PM, danl_miller_at_b... (danl_miller) wrote:
>
> >--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> >> At 11:54 AM 2/24/2002, Rene Rivera wrote:
> >>
> >> >There has been some discussion before as to what installing Boost
> >should
> >> >be,
> >> >and that is what we seem to want to discuss now. Question is, as a
> >"Boost
> >> >user" what do think a Boost install should do?
> >>
> >> Rene,
> >>
> >> This is probably a naive view, but shouldn't Boost install do
> >whatever is
> >> necessary to make it look like Boost is part of the compiler
> >supplied
> >> object library set? (Even better if it can also make the Boost
> >headers
> >> look like they were part of the compiler supplied header set.)
> >>
> >> --Beman
> >
> > Colocating Boost libraries with compiler-supplied libraries (and
> >colocating Boost headers with compiler-supplied headers) would be
> >problematic.
>
> [snip]
>
> I agree, it causes more problems than it solves.
>
> Takign a look at what other source type programs do (gcc, emacs,
perl, etc.).

Don't look at what other programs do; look at what other *libraries* do.

> It seems that versioning the subdirectories under a common prefix
location is
> a workable practice. Would then something like the following work
for us?
>
> $prefix/include/boost/1.27.0/boost/.../*.hpp
> $prefix/lib/boost/1.27.0/*.(a,so)
> $prefix/share/boost/1.27.0/tools/build/*.jam

That's offensive.

Why would you do this? The versioning "problem" is solved by autoconf
and libtool.

If someone wants to install multiple boost versions on their system at
once, the solution is simple: don't put them under the same prefix.

Braden


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk