Steven T. Hatton wrote:
On Saturday 04 September 2004 20:18, David Abrahams wrote:
"Steven T. Hatton"
writes: On Friday 03 September 2004 12:06, David Abrahams wrote:
"Steven T. Hatton"
writes: What are the "Boost.Build system files"?
The contents of tools/build/v1 or tools/build/v2 depending on which version of Boost.Build you're using.
I could be mistaken, but I don't believe the documentation is clear on this point.
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.
But that means everything is installed in the system's directory structure. That is not an ideal strategy for my purposes. All other libraries and tools I have are installed in my own user space.
Your choice. If it were me I'd keep the installed files out of the Boost source tree.
This is something I found confusing. I typically download a tarball, extract it, and run
./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.
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#Envir...
[cut, long quote from gcc docs] So what's your point? Or what's your question? 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.
should contain /usr/local/include/boost-1_31 and my LIBRARY_PATH, and LD_LIBRARY_PATH should contain /usr/local/lib?
You could do it that way. Or you can refer to the installed libraries with absolute paths, or you can add -l/usr/local/include/boost-1_31 to your compiler options. Specifically how you point your build tools at the Boost components is not for us to prescribe.
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. And yes Boost.Build uses them, but only to set them so that those secondary dependencies are correctly resolved. But no it doesn't use them in the sense of affecting how it works. So you setting them will only tangentially affect the build behavior. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq