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. 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.
./configure --prefix=$APPNAME_HOME && make && make install
That would be equivalent to what I expected from running
bjam "-sTOOLS=gcc" install
It is equivalent.
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.
Is there anything else I need to do in order to compile my programs against the boost headers and libraries?
Add the include/ directory to your #include path and the lib/ directory to your library search path?
By that am I to understand that when using the default installation my CPLUS_INCLUDE_PATH
I don't know what that is. I just meant add -I/usr/local/include/boost-1_31 to your compiler options.
The documentation does not explicitly state that CPLUS_INCLUDE_PATH is for C++, but I am left with no other conclusion than that as the intent.
http://gcc.gnu.org/onlinedocs/gcc-3.3.3/gcc/Environment-Variables.html#En vironment%20Variables
[cut, long quote from gcc docs]
So what's your point? Or what's your question?
I just wanted to show the reason for my mentioning the CPLUS_INCLUDE_PATH, and some context.
And what Dave meant to say is that it's up to you to decide how to add the Boost include directory to your C++ projects.
Now that I believe I have things more or less configured properly, I can try to figure out how to work with bjam and the Jamefile/Jamrules to build my projects.
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. -- Regards, Steven