Re: [Boost-build] Has BBv2 behaviour changed wrt <runtime-link>static?

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
> are
> 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
> bjam
> 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

        <toolset>borland:<link>static

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.

- Volodya