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