From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-10-06 14:24:43
John Maddock wrote:
> Folks, in the last release the math_info test looked like this:
> [ run libs/config/test/math_info.cpp : : :
> <test-info>always_show_run_output <toolset>borland:<runtime-link>static ]
> The <runtime-link>static was required to get the program to link (there
> unresolved externals to std::numeric_limits otherwise). It's a
> compiler/std lib bug, but since the whole purpose of the test is to make
> some useful diagnostic information available to developers, I'd rather
> work around it, than mark it up.
> However, that workaround no longer seems to work: now with the
> "<toolset>borland:<runtime-link>static" present then that test is simply
> no longer built unless you explicitly specify runtime-link=static on the
> command line :-(
> So... has something been deliberately changed? If so then how should we
> work around such issues, or can we no longer do so?
In fact, I'm not sure why it works on command line :-(
We have this code in Jamroot:
rule handle-static-runtime ( properties * )
# This property combination is dangerous.
# Ideally, we'd add constraint to default build,
# so that user can build with property combination
# by hand. But we don't have any 'constraint' mechanism
# for default-build, so disable such builds in requirements.
# For CW, static runtime is needed so that
# std::locale works.
if <link>shared in $(properties)
&& <runtime-link>static in $(properties)
&& ! ( <toolset>cw in $(properties) )
return <build>no ;
and it affects your target, too. I suspect the easiest way to address
this is add
to your target's requirements. I've tried, and it works for me.
I've also committed a patch that make --debug-building tell
that a target is skipped because of <build>no in properties.
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