Boost logo

Boost Users :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-09-06 00:08:31


Steven T. Hatton wrote:

> On Saturday 04 September 2004 20:18, David Abrahams wrote:
>
>>"Steven T. Hatton" <hattons_at_[hidden]> writes:
>>
>>>On Friday 03 September 2004 12:06, David Abrahams wrote:
>>>
>>>>"Steven T. Hatton" <hattons_at_[hidden]> 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#Environment%20Variables

[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

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net