|
Boost Users : |
From: Daryle Walker (darylew_at_[hidden])
Date: 2004-10-01 08:12:15
On 9/8/04 10:13 AM, "David Abrahams" <dave_at_[hidden]> wrote:
> Daryle Walker <darylew_at_[hidden]> writes:
>
>> On 9/7/04 10:36 AM, "David Abrahams" <dave_at_[hidden]> 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
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