[Boost-build] Projects requirements and alternative selection

Subject: [Boost-build] Projects requirements and alternative selection
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2009-04-15 08:38:28

Hi,

I'm experiencing some "problems" with target selection. A simplified 
example:

-------------------- Jamroot ------------------
project foo
 : requirements
 <link>static
 <threading>multi
 <runtime-link>shared

 : default-build
 debug

 ;

# release
lib bar
 :
 : <file>a.lib <threading>multi <link>static <runtime-link>shared 
<variant>release
 ;

# debug
lib bar
 :
 : <file>a_d.lib <threading>multi <link>static <runtime-link>shared 
<variant>debug
 ;
------------------ Build output -----------------------
>bjam
error: No best alternative for ./bar
    next alternative: required properties: <link>static <runtime-link>shared 
<threading>multi <variant>release
        not matched
    next alternative: required properties: <link>static <runtime-link>shared 
<threading>multi <variant>debug
        not matched
...found 1 target...
----------------------------------------------------

Note that if I declare e.g. an exe target that references the 'bar' lib, the 
correct library is selected and linked with, but the above error messages 
still appear (build is not aborted). What seems to be the culprit is that 
threading defaults to "single" and link to "static" and that this is added 
to the build request. This is the output from some tracing added to 
select-alternatives in targets.jam:

Original: <debug-symbols>on
<inlining>off
<optimization>off
<runtime-debugging>on
<variant>debug

With defaults: <asynch-exceptions>off
<debug-store>object
<debug-symbols>on
<embed-manifest>on
<exception-handling>on
<extern-c-nothrow>off
<hardcode-dll-paths>true
<host-os>windows
<inlining>off
<install-dependencies>off
<link>shared
<midl-robust>yes
<midl-stubless-proxy>yes
<optimization>off
<os>NT
<pch>on
<profiling>off
<rtti>on
<runtime-debugging>on
<runtime-link>shared
<stdlib>native
<suppress-import-lib>false
<symlink-location>project-relative
<target-os>windows
<threading>single
<toolset-msvc:version>8.0
<toolset>msvc
<user-interface>console
<variant>debug
<warnings-as-errors>off
<warnings>on

Is this as expected - I had a gut feeling that the requirements set by 
"project" should be added to the "build" request for the bar lib in the 
above scenario?

I've tried the above using Boost.Build from trunk as well as from 1.34.1. 
Toolset is msvc (set in user-config.jam).

Thanks / Johan