Re: [Boost-users] Re: Are BOOST_BUILD_PATH && BOOST_ROOT necessary?

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:

The default within the Boost tree is v1. The default elsewhere depends on where your boost-build.jam file points.

...

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.

...

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 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.

...

...

...

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... # Begin quote Some additional environments variables affect the behavior of the preprocessor. CPATH C_INCLUDE_PATH CPLUS_INCLUDE_PATH OBJC_INCLUDE_PATH Each variable's value is a list of directories separated by a special character, much like PATH, in which to look for header files. The special character, PATH_SEPARATOR, is target-dependent and determined at GCC build time. For Windows-based targets it is a semicolon, and for almost all other targets it is a colon. CPATH specifies a list of directories to be searched as if specified with -I, but after any paths given with -I options on the command line. This environment variable is used regardless of which language is being preprocessed. The remaining environment variables apply only when preprocessing the particular language indicated. Each specifies a list of directories to be searched as if specified with -isystem, but after any paths given with -isystem options on the command line. In all these variables, an empty element instructs the compiler to search its current working directory. Empty elements can appear at the beginning or end of a path. For instance, if the value of CPATH is :/special/include, that has the same effect as -I. -I/special/include. #End quote

...

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. -- Regards, Steven