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

From: David Abrahams (dave_at_[hidden])
Date: 2004-09-04 19:18:51

"Steven T. Hatton" <hattons_at_[hidden]> writes:

> On Friday 03 September 2004 12:06, David Abrahams wrote:
>> "Steven T. Hatton" <hattons_at_[hidden]> 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