Boost logo

Boost-Build :

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-08-01 13:46:04


John Maddock wrote:
>>Recently, I've tried to build some application that uses
>>Boost.Program_options
>>on windows. The build failed, attempting to auto-link to the
>>program_options
>>library.
>>This clearly should not happen -- if I use Boost.Build to link to a
>>library,
>>I don't want autolinking at the same time. So, I've added
>><define>BOOST_PROGRAM_OPTIONS_NO_LIB to the usage-requirements of
>>program_options target.
>>
>>Now:
>>1. Should we add the same to all other libraries in Boost?
>>2. Should we just add BOOST_ALL_NO_LIB as top-level usage-requirement?
>>
>>Comments?
>
>
> Yikes that sounds to me like a terrible "fix", we've found several bugs in
> the past when the auto-link and boost.build link options didn't match up,
> and that's the point, they should match up and be in synch. If they're not
> then the autolink code is useless. As long as Boost.Build mangles the
> library file names in the same way as the autolink code expects (which is
> how we document the mangling scheme used by Boost.Build as well at least for
> v1), then no fixes like this should be necessary. So, do the library file
> names match up with what autolink expects, and if not why not?

Even if they do match, autolink expect boost libraries to be on the
compiler library search path. With boost.build we don't need to change
library search path, but we specify dependent targets with complete
paths instead. So autolink code is already prettu useless if boost
libraries are linked to projects build by BB.

Do I miss something?

Andrey

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk