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

"Steven T. Hatton" writes:

On Friday 03 September 2004 12:06, David Abrahams wrote:

...

"Steven T. Hatton" writes:

...

From reading the documentation on boost.org, I have gotten the impression I don't need to set $BOOST_BUILD_PATH and $BOOST_ROOT.

Correct.

I've discovered BOOST_ROOT used in different places within the boost source tree. I don't recall exactly where, but somewhere in the sourcetree there is a comment telling me that most of the builds will require that I have $BOOST_ROOT correctly set. This is one place I found a reference to $BOOST_ROOT:

You don't need to set it. It is set automatically for builds that use Boost Jamfiles. See the Jamrules file in the root directory of your Boost installation.

subproject libs/test/example ;

rule boost-test-example ( example-name : lib-name ) { exe $(example-name) : $(example-name).cpp <lib>../build/$(lib-name) : <sysinclude>$(BOOST_ROOT) <stlport-iostream>on <borland><*><cxxflags>-w-8080 ; }

Can I assume that is ignored if it isn't set?

No.

I just removed the user space install, and started with a fresh source tree from the tarball. I have no boost related environment variable set. I did find it necessary to:

export PYTHON_ROOT=/usr export PYTHON_VERSION=2.3

Yes, as noted in the documentation if you want to build the Boost.Python library you may need to set those. If you don't need to build that lib, you can leave them unset.

...

It doesn't hurt for you to set BOOST_ROOT, as long as you set it accurately. But you shouldn't need to.

Does it change the behavior of bjam to have it set?

No.

I'm a bit confused regarding which bjam version is invoked by default. The documentation suggests v1 will be invoke under certain conditions. All of my attempts to use the --v2 switch explicitly have resulted in a significant number of errors. That makes me thing the default is v1.

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

...

...

I'm using SuSE Linux 9.1 on a P4 box. Some basic questions are these:

When I downloaded and built boost, I first fetched the source for bjam.

Unneccessary, but it shouldn't hurt. The bjam sources are in the tools/build/jam_src directory of your Boost installation.

What do you mean by "Boost installation"?

Well, SF is currently down, but if you download boost-1.31.0 from http://sourceforge.net/project/showfiles.php?group_id=7586 and decompress it, the result is a boost source installation.

When I ran `bjam install' files were copied to

/usr/local/include/boost-1_31/ # an acceptable location and /usr/local/lib # something I would never knowingly choose as a default

Take it up with Rene. Rene?

I manually coppied the bjam executable (which I also built from the boost-1_31_0 tarball.) to /usr/local/bin. Beyond that, everything I got from the tarball still sits in the temporary directory I used for compilation. I Shall I assume you mean to call that source tree, and the files produced by my running the script bjam build.sh and subsequent invocations of bjam, the "Boost installation"?

No, I just meant the source tree.

This is certainly not consistent with the way the term installation is used with the gnu autotools. Typically I would call the files placed in the --prefix directory the installation. There's nothing wrong with using a different definition, so long as we are aware of what it means in the given context.

Now we know ;-)

...

...

This is the name of the file I downloaded: boost-jam-3.1.10.tgz It compiled quite nicely, and I copied the resulting bjam jam mkjambase and yyacc to a location in my path.

Why did you copy anything other than bjam?

I wasn't sure if the other executables might prove useful in the future. Since the script put four executables into the bin.linuxx86/ where the bjam file was placed, I assumed all of these were intended for my use.

The first three could be, but you really don't need anything other than bjam. If you just follow the instructions you won't copy anything you don't need.

...

...

Are there necessary configuration file that I need to have visible to these programs, even if they are not colocated?

Not exactly.

http://www.boost.org/tools/build/jam_src/#jambase_replacement

Ah yes, the source of much of my confusion:

"The Boost.Build v2 initialization behavior has been implemented. This behavior only applies when the executable being invoked is called "bjam" or, for backward-compatibility, when the BOOST_ROOT variable is set."

I'm not sure what that statement means. In particular, what is meant by "this behavior"? Does this mean the v2 behavior, or specifically the behavior described in the subsequent text?

They are one and the same.

"We attempt to load "boost-build.jam" by searching from the current invocation directory up to the root of the file-system. This file is expected to invoke the boost-build rule to indicate where the Boost.Build system files are, and to load them."

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.

"The boost-build rule adds its (optional) argument to the front of BOOST_BUILD_PATH, and attempts to load bootstrap.jam from those directories."

Is this bootstrap.jam for use when building my own projects, or only for use when building Boost libraries?

Don't worry about it; be happy. These are the files that bootstrap the build system. All you need to know about is that boost-build.jam points at tools/build/v1 (in your case).

Typically bootstraps are used in the gnu world as a means of building the gcc compiler, or Emacs which needs to be able to compile its own Lisp. They are not used after the first build, and do not become part of the installed package.

Bootstrap has a more general meaning.

...

describes the file that bjam expects to see when it starts up. You might also drop a Jamrules file in the root directory of your own Boost.Build project (if you use bjam for your own project) that contains:

project boost : path/to/boost_1_31_0 ;

Does that mean the root of the directory structure of the tarball?

If by "that" you mean "path/to/boost_1_31_0", yes.

...

Well, yeah, except that using the BOOST_ROOT directory for your --prefix is probably a bad idea. I would leave the --prefix option off.

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.

...

...

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.

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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com