Boost logo

Boost Users :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-09-06 09:20:08


Steven T. Hatton wrote:

> On Monday 06 September 2004 01:08, Rene Rivera wrote:
>
>>Steven T. Hatton wrote:
>
>
>>That's because V2 is experimental and not shown to users normally.
>>Usually people actively using the build system know the difference, not
>>people just doing the default install.
>
> The part I was confused about is what "Boost.Build system" meant in any case.
> This may once have been clear, and lost its clarity when v2 was introduced.

That's certainly true, although it's less confusing now that they both
live in separate directories. Just try to imagine the confusion when we
first had both versions living in the same dir all mixed together :->

> There's lots of good documentation for Boost. And for Boost.Build. My
> purpose is not to attempt to prove otherwise. I'm just trying to let you
> know what I got hung up on when working through the install. I've come to
> realize that part of my confusion comes from the fact that there is a build
> proceedure for bjam, a build procedure for Boost, and a build proceedure for
> projects using Boost and Boost build. I didn't have all that clear in my
> head at first.

Understood. We tend to concentrate our efforts on documenting the first
steps of build+install as it's traditionally been the largest stumbling
block for first time users. And use the e-lists to direct people in the
other cases.

>>>When using the example above using ./configure, I can delete everything
>>>within the extracted image. All I need in order to use the package would
>>>be placed in $APPNAME_HOME by make install.
>>
>>And you could... depending on your definition of _use_. If all you do is
>>compile code that uses Boost all you should need is what the "install"
>>copies to the --prefix location. If you mean something more, then no you
>>can't.
>
> I believe the something more means using Boost.Build. I guess there's nothing
> else in the Boost distribution I would want to keep around except for
> examples and documentation.

The Boost.Build case is easy.. If you intend on using BBv1 copy
./tools/build/v1 to your project. OR if you want to *experiment* with
BBv2, copy ./tools/build/v2 to your project. In either case you should
direct questions to the Boost.Build list, see
http://www.boost.org/more/mailing_lists.htm#projects .

Documentation and examples are harder. It's the goal to eventually have
install also deal with documentation, but that will likely have to wait
until all the documentation is translated to Boost.Book format and a
single PDF file can be generated. Examples have so many
interdependencies that it would be problematic trying to install those.

>>>Does Boost.Build use these variables? I noticed some output that showed
>>>the values of LD_LIBRARY_PATH. My understanding is that this is for the
>>>loader to use at runtime. The LIBRARY_PATH is intended to be used at
>>>compile time.
>>
>>Only partially true. As it turns out the Linux linker (and others) uses
>>LD_LIBRARY_PATH on secondary dependencies of shared libraries during
>>linking/compile time.
>
>
> Can you provide a reference that discusses how this all works? I have to
> confess, I am confused about these issues. I've read blatantly contradictory
> descriptions of how these variable are supposed to be used. And then there's
> the ld.so.conf and ldconfig to add to the confusion.

Confusing and buggy. Unfortunately I don't think there is "official"
documentation on how they all actually work, only how they are supposed
to work. My knowledge on how they do work is experimental, you might be
able to search for my comments in the Boost.Dev, and Boost.Build lists
though.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net