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

From: Steven T. Hatton (hattons_at_[hidden])
Date: 2004-09-06 03:09:07

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