Are BOOST_BUILD_PATH && BOOST_ROOT necessary?

Steven T. Hatton

3 Sep 2004 3 Sep '04

4:05 a.m.

From reading the documentation on boost.org, I have gotten the impression I don't need to set $BOOST_BUILD_PATH and $BOOST_ROOT. I'm more than a little confused about how I should use the boost libraries. Part of this comes from the fact that it is not clear to me exactly where the demarkation is between using the build system to build boost, and using it to build my own programs. Some of my confusion comes from the appearant change in configuration requirements described in the documentation. It is suggested I don't need the environment variable used with earlier releases. One of these variables is $BOOST_ROOT, which the documentation used as an example of how to build boost. That example was exactly what I successfully (I believe) build the libraries with.

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. 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. Are there anything other things such as configuration files I need to reside with the binary executables? Are there necessary configuration file that I need to have visible to these programs, even if they are not colocated? I then build boost with the command: bjam --prefix=$BOOST_ROOT "-sTOOLS=gcc" install after setting my BOOST_ROOT the way I wanted it. That resulted in two directories being placed in $BOOST_ROOT/ one is called $BOOST_ROOT/include/ the other is called $BOOST_ROOT/lib/. Under $BOOST_ROOT/include/ I have <path>/boost-1_31/boost/ which contains dozens of header files. I added $BOOST_ROOT/include/boost-1_31 to my $INCLUDE_PATH, and $BOOST_ROOT/lib to my $LIBRARY_PATH and $LD_LIBRARY_PATH variables. Is this the correct way to configure my system to use boost? Is there anything else I need to do in order to compile my programs against the boost headers and libraries? Will the boost libraries work as well as other, comperable libraries using autotools rather than bjam? Are there any special accommodations I need to make in order to use boost with the gnu build tools? Do I need to do anything special to use boost with bjam that does not involve placing files in my current project directories? For example, do I need to provide a global configuration file of some kind? Is it a preferred option, even if not strictly required? There is much remaining in the source directory where I compiled boost. Is that something I need to also put in an accessible place on my system? If so, what so I need to put where, and how to I modify my environment variable to facilitate its use? -- Regards, Steven

Show replies by date

David Abrahams

3 Sep 3 Sep

4:06 p.m.

"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'm more than a little confused about how I should use the boost libraries. Part of this comes from the fact that it is not clear to me exactly where the demarkation is between using the build system to build boost, and using it to build my own programs. Some of my confusion comes from the appearant change in configuration requirements described in the documentation. It is suggested I don't need the environment variable used with earlier releases. One of these variables is $BOOST_ROOT, which the documentation used as an example of how to build boost. That example was exactly what I successfully (I believe) build the libraries with.

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

...

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.

...

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?

...

Are there anything other things such as configuration files I need to reside with the binary executables?

No.

...

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 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 ; But for building from within the Boost tree itself, thes are already taken care of.

...

I then build boost with the command:

bjam --prefix=$BOOST_ROOT "-sTOOLS=gcc" install

after setting my BOOST_ROOT the way I wanted it. That resulted in two directories being placed in $BOOST_ROOT/ one is called $BOOST_ROOT/include/ the other is called $BOOST_ROOT/lib/. Under $BOOST_ROOT/include/ I have <path>/boost-1_31/boost/ which contains dozens of header files. I added $BOOST_ROOT/include/boost-1_31 to my $INCLUDE_PATH, and $BOOST_ROOT/lib to my $LIBRARY_PATH and $LD_LIBRARY_PATH variables. Is this the correct way to configure my system to use boost?

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

...

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?

...

Will the boost libraries work as well as other, comperable libraries using autotools rather than bjam? Are there any special accommodations I need to make in order to use boost with the gnu build tools?

I don't know much about those tools, so I can't really say. Maybe someone else can.

...

Do I need to do anything special to use boost with bjam that does not involve placing files in my current project directories? For example, do I need to provide a global configuration file of some kind? Is it a preferred option, even if not strictly required?

No.

...

There is much remaining in the source directory where I compiled boost. Is that something I need to also put in an accessible place on my system?

No.

...

If so, what so I need to put where, and how to I modify my environment variable to facilitate its use?

-- Dave Abrahams Boost Consulting http://www.boost-consulting.com

Steven T. Hatton

4 Sep 4 Sep

2:05 a.m.

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: 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? 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

...

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

...

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

...

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

...

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

...

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?

...

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.

...

...
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 should contain /usr/local/include/boost-1_31 and my LIBRARY_PATH, and LD_LIBRARY_PATH should contain /usr/local/lib? -- Regards, Steven

David Abrahams

5 Sep 5 Sep

12:18 a.m.

"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

Rene Rivera

2:56 a.m.

David Abrahams wrote:

...

"Steven T. Hatton" writes:

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

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?

To the rescue ;-) Installing to /usr/local/lib was the most requested location by users. The majority of users did *not* want to modify the standard search location variables or call ldconfig (or whatever the equivalent is for each platform). As for knowing about that choice, it is mentioned in the documentation, and in the inline help. Just as it is for "configure" style tools. You could have done a: bjam --help, and seen: C:\Boost\boost_1_31_0>bjam --help Usage: bjam [options] [install|stage] * install Installs to the configured location(s). * stage Stages the build products only to common stage location. Options: --help This message. -sTOOLS=<toolsets> Indicates the tools to build with. Locations: --prefix=PREFIX Install architecture independent files here. Default; C:\Boost on Win32 Default; /usr/local on Unix. Linux, etc. ----------------------------[ and there you have the default and how to change the default ;-) ]

...

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

Indeed it does... from Merriam-Webster: Pronunciation: 'büt-"strap Function: noun 1 plural : unaided efforts -- often used in the phrase by one's own bootstraps Function: adjective 1 : designed to function independently of outside direction : capable of using one internal function or process to control another <a bootstrap operation to load a computer> Just because the bootstrap happens each time doesn't make it less of a bootstrap :-> -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

Steven T. Hatton

11:34 p.m.

On Saturday 04 September 2004 22:56, Rene Rivera wrote:

...

David Abrahams wrote:

...
"Steven T. Hatton" writes: ...

...

Installing to /usr/local/lib was the most requested location by users. The majority of users did *not* want to modify the standard search location variables or call ldconfig (or whatever the equivalent is for each platform).

usr/local/lib is not an uncommon default. I typically install virtually all my (dozens of) development libraries in my own user space, and add them to my user environment variables. My systems administrator - who has well over a decade of solid experience - does not let me mess with the base OS configuration unless absolutely necessary. I am, BTW, the systems administrator.

...

As for knowing about that choice, it is mentioned in the documentation, and in the inline help. Just as it is for "configure" style tools. You could have done a: bjam --help, and seen:

Yes, that is how this discussion got started. I had followed the example in the documentation, and set my own directory for --prefix. The way it's looking to me now, the whole /install/ action is spurious for my situation. Installing Boost means extracting it to the installation location and building it in place. Following that I need to set my environment variables to reference the appropriate locations. In the case of Boost I believe the best thing for me to do is: #Assume BOOST_HOME to be my equivalent to BOOST_ROOT test "$PWD" = "$BOOST_HOME" && ln -s stage/lib . && ln -s boost include I will observe the $BOOST_HOME/bin directory does not seem to hold what I expect to find in a <path to>/bin directory. I did not refrence any documentation when writing the following, so it may be subject ot refinement or correction. My expectation of an installation is that it reflects the structure of a Unix file system. In the following 'info' is not from standard Unix, but the remainder of the directory names are. If you have BOOST_ROOT set 'correctly' this will generate the directory structure I would expect to find in a package installed on a Unix or Unix-like OS when --prefix=$BOOST_ROOT: UP="lib bin include sbin man share libexec info";\ for d in $UP; do echo "$BOOST_ROOT/$d"; done $BOOST_ROOT/lib # libraries for loading at runtime or linking at compile time $BOOST_ROOT/bin # user executables such as bjam, etc $BOOST_ROOT/include # header files intended for use by developers $BOOST_ROOT/sbin # executables intended for systems administration $BOOST_ROOT/man # Unix manual pages for Boost, if they exist $BOOST_ROOT/share # platform independent resources: html docs, dtds, Jambase? $BOOST_ROOT/libexec # executables that I don't use very often. $BOOST_ROOT/info # GNU Info documentation for Boost, if it exists Since properly conforming (to GNU standards) GNU packages are predictable, I am able to do the following: export GNU=$ORG/gnu #test -z "$GNU_GCC" && export GNU_GCC=$GNU/gcc-3.4.0 #test -n "$GNU_GCC" || export GNU_GCC=$GNU/gcc-3.3.3 export GNU_MAKE=$GNU/make-3.80 export GNU_AUTOCONF=$GNU/autoconf-2.59 export GNU_AUTOGEN=$GNU/autogen-5.5.7 export GNU_AUTOMAKE=$GNU/automake-1.8.4 export GNU_GNOME=/opt/gnome export GNU_LIBTOOL=$GNU/libtool-1.5.6 export GNU_TEXINFO=$GNU/texinfo-4.7 export GNU_EMACS=$GNU/emacs-cvs #export GNU_DDD=$GNU/ddd-3.3.8 export GNU_GDB=$GNU/gdb-6.1 export GNU_DDD=$GNU/ddd-cvs export GNU_LIB3DS=$GNU/lib3ds-1.2.0 export GNU_TOOLSMANUAL=$GNU//toolsmanual-0.1.5 export GNU_LIST="$GNU_TOOLSMANUAL\ $GNU_LIB3DS\ $GNU_DDD\ $GNU_GDB\ $GNU_EMACS\ $GNU_TEXINFO\ $GNU_LIBTOOL\ $GNU_GNOME\ $GNU_AUTOMAKE\ $GNU_AUTOGEN\ $GNU_AUTOCONF\ $GNU_MAKE\ " # $GNU_GCC\ GNU_MANPATH="" GNU_PATH="" GNU_INFOPATH="" GNU_LIBRARY_PATH="" GNU_INCLUDE_PATH="" for g in $GNU_LIST;do GNU_MANPATH=$g/man:$GNU_MANPATH GNU_PATH=$g/bin:$GNU_PATH GNU_INFOPATH=$g/info:$GNU_INFOPATH GNU_LIBRARY_PATH=$g/lib:$GNU_LIBRARY_PATH GNU_INCLUDE_PATH=$g/include:$GNU_INCLUDE_PATH done; I then use the GNU_* variables to set the value of my standard environment variables. It's not perfect, but it is effective. SuSE uses a somewhat different approach to configuration. I believe what it amounts to is choosing a different order of traversal over a multiply connected graph.

...

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

Indeed it does... from Merriam-Webster:

Yes it can be used to describe the mechanism that sets a multivibrator built with vacuum tubes into oscillation, or to start a computer by loading instructions stored in firmware which cause the loading of instructions stored on a harddrive or other resource, such as a shared network image of a harddrive. I use the term to describe starting any process that needs some crucial piece of information about itself. As I pointed out earlier, it's not wrong to use words with different connotations in different situations, but it can be confusing. I'm letting you know what was confusing to me when I read the documentation. That does not necessarily mean the documentation is at fault. -- Regards, Steven

Steven T. Hatton

6 Sep 6 Sep

3:19 a.m.

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

Rene Rivera

5:08 a.m.

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

Steven T. Hatton

8:09 a.m.

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

Rene Rivera

2:20 p.m.

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

David Abrahams

7 Sep 7 Sep

2:36 p.m.

"Steven T. Hatton" writes:

...

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.

And there are at least two different ways to use the Boost libraries: 1. Using Boost.Build to build your own projects, link against "un-installed" libraries that are automatically built on demand and updated when the Boost sources and/or libraries change. 2. Using whatever build system you like (including possibly Boost.Build), link against the versions you've installed using bjam --install Method 2 is mostly for people who don't want to use Boost.Build for their own projects, or who want to share prebuilt Boost library images among several Boost developers. This stuff should be made clearer in the docs, with explanations of how to do it. Maybe it would make sense to do something before the upcoming release. I realize we're retiring v1 forthwith, but then who knows how long it'll be until the next Boost release? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

Daryle Walker

7:32 p.m.

On 9/7/04 10:36 AM, "David Abrahams" wrote: [SNIP]

...

And there are at least two different ways to use the Boost libraries:

1. Using Boost.Build to build your own projects, link against "un-installed" libraries that are automatically built on demand and updated when the Boost sources and/or libraries change.

2. Using whatever build system you like (including possibly Boost.Build), link against the versions you've installed using bjam --install

Method 2 is mostly for people who don't want to use Boost.Build for their own projects, or who want to share prebuilt Boost library images among several Boost developers.

There's also: 3. Don't use Boost.Build (or bjam) at all! Include the appropriate Boost files in your project and compile them like your custom code. This would minimize the chances of the Boost code getting compiled with incompatible options from your custom code. You don't really need to add any Boost header files to be compiled, as long as they're still in the #include search paths. However, any mandatory source code for all applicable Boost libraries has to be add to the project file, and we've scattered that over several directories.

...

This stuff should be made clearer in the docs, with explanations of how to do it. Maybe it would make sense to do something before the upcoming release. I realize we're retiring v1 forthwith, but then who knows how long it'll be until the next Boost release?

-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

David Abrahams

8 Sep 8 Sep

2:13 p.m.

Daryle Walker writes:

...

On 9/7/04 10:36 AM, "David Abrahams" wrote:

[SNIP]

...
And there are at least two different ways to use the Boost libraries:

1. Using Boost.Build to build your own projects, link against "un-installed" libraries that are automatically built on demand and updated when the Boost sources and/or libraries change.

2. Using whatever build system you like (including possibly Boost.Build), link against the versions you've installed using bjam --install

Method 2 is mostly for people who don't want to use Boost.Build for their own projects, or who want to share prebuilt Boost library images among several Boost developers.

There's also:

3. Don't use Boost.Build (or bjam) at all! Include the appropriate Boost files in your project and compile them like your custom code.

This would minimize the chances of the Boost code getting compiled with incompatible options from your custom code.

1. also minimizes those chances, and it doesn't have the disadvantage that you might build with options that are incompatible with the Boost library code you're using. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

Daryle Walker

1 Oct 1 Oct

1:12 p.m.

On 9/8/04 10:13 AM, "David Abrahams" wrote:

...

Daryle Walker writes:

...
On 9/7/04 10:36 AM, "David Abrahams" wrote:

[SNIP]

...
And there are at least two different ways to use the Boost libraries:

1. Using Boost.Build to build your own projects, link against "un-installed" libraries that are automatically built on demand and updated when the Boost sources and/or libraries change.

2. Using whatever build system you like (including possibly Boost.Build), link against the versions you've installed using bjam --install

Method 2 is mostly for people who don't want to use Boost.Build for their own projects, or who want to share prebuilt Boost library images among several Boost developers.

There's also:

3. Don't use Boost.Build (or bjam) at all! Include the appropriate Boost files in your project and compile them like your custom code.

This would minimize the chances of the Boost code getting compiled with incompatible options from your custom code.

1. also minimizes those chances, and it doesn't have the disadvantage that you might build with options that are incompatible with the Boost library code you're using.

The only way that [1] could have an advantage over [3] in this scenario is if Boost code needs options that are neutral to the custom code. That can be fixed by transferring the appropriate options to the custom project file. (Those differences in options should have been expressed in Boost.Config anyway!) If the Boost code and custom code need incompatible sets of options, the user is screwed for all 3 ways. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

Steven T. Hatton

4 Sep 4 Sep

4:24 a.m.

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. ... http://www.boost.org/tools/build/jam_src/#jambase_replacement

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 ;

I set the BOOST_ROOT to the value that I thought it should have and was able to run bjam on a very simple project. I then put the value of BOOST_ROOT in a Jamrules file in the same directory and unset the BOOST_ROOT variable. I attempted to run bjam again and was informed that it was unable to find "boost-build.jam" This is the entire content of the directory: //main.cc #include <iostream> int main() { std::cout << "Hello Boost Jam!\n"; } # Jamfile project-root ; exe hello : main.cc ; #Jamrules project boost : /<path to>boost/1_31_0 ; Have I done something wrong? -- Regards, Steven

David Abrahams

5 Sep 5 Sep

12:23 a.m.

"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. ... http://www.boost.org/tools/build/jam_src/#jambase_replacement

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 ;

I set the BOOST_ROOT to the value that I thought it should have

Whatever. You don't need to set that variable, provided you set up boost-build.jam.

...

and was able to run bjam on a very simple project. I then put the value of BOOST_ROOT in a Jamrules file in the same directory and unset the BOOST_ROOT variable. I attempted to run bjam again and was informed that it was unable to find "boost-build.jam"

Which is why I pointed you at http://www.boost.org/tools/build/jam_src/#jambase_replacement The most general approach is to create a boost-build.jam

...

This is the entire content of the directory:

//main.cc #include <iostream>

int main() { std::cout << "Hello Boost Jam!\n"; }

# Jamfile project-root ; exe hello : main.cc ;

#Jamrules project boost : /<path to>boost/1_31_0 ;

Have I done something wrong?

Add a boost-build.jam somewhere in your directory or a parent: boost-build path/to/boost_1_31_0 ; -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

7361

Age (days ago)

7389

Last active (days ago)

List overview

Download

15 comments

4 participants

participants (4)

Daryle Walker
David Abrahams
Rene Rivera
Steven T. Hatton