|
Boost-Build : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-02 00:26:14
On Monday 01 August 2005 21:36, 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?
They don't. When library targets are generate to variants directories, using
that name mangling scheme does not seem necessary -- it's all in the target
path already.
- Volodya
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
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