[patch] Re: feature threading does not work

From: Christopher Currie (gclbb-jamboost_at_[hidden])
Date: 2003-08-25 18:33:02

David Abrahams wrote:
> I don't think Konstantin is imagining the problem. For example, I
> wanted to use Boost.Threads in a project. First I discovered its
> Jamfile.v2 wasn't set up to build on Windows... but that was
> comparitively easy to fix. Then I found it didn't seem to have
> multithreading in its requirements, so I added it. When I built it,
> however, it still tried to build single-threaded. So I added it to
> the default build also and it worked. That seems redundant to me. 
>
> I'm building my application as a bunch of libraries, so I added
> <library>/boost/thread to one of my lib's requirements (BTW, I had to
> find this by trial-and-error -- I should probably know this stuff,
> but unless there's documentation somewhere I tend to lose track).
> 
> Now my library would still build single-threaded unless I added
> <threading>multi to the default build (even adding it to the
> requirements didn't help).

There's a bug in the way that targets are reduced by usage-requirements. 
The attached patch will make things better, allowing other targets to 
build when the build-spec doesn't match one of them. The following 
Jamfile provides a use case:

# threading/Jamfile
exe single : single.cpp : <threading>single ;

exe multi : multi.cpp : <threading>multi ;

exe dontcare : dontcare.cpp ;

With the patch applied, building with <threading>single (the default) 
will build single and dontcare, and warn about not being able to build 
multi. With <threading>multi, it will build multi and don't care, with a 
warning about single. I can build all three (dontcare twice) if I 
specify "threading=single,multi", although it will also warn twice.

Even with this patch, I think there's an discussion due here regarding 
the way BBv2 resolves feature conflicts wrt link-incompatible features 
and unrelated main-targets:

* Should a top-level main-target (one that is not a dependency of 
anything) be allowed to override a project's default-build features? 
(e.g. Should multi (above) be built, even if the build-spec says 
<threading>single?) Should it be different if a feature is specified by 
the user or implied by a default?

* Should the default build-spec instead be "single,multi"? This would 
cause most projects to be built twice by default, which is probably not 
what we want.

There's more to discuss here, but you get the idea. There's also a 
related issue that someone brought up a while ago regarding whether 
<threading> should be link-incompatible in the first place.

Christopher

 --------------030602070803040002060509 Content-Type: text/plain;
name="threading[1].patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="threading[1].patch"

Index: new/targets.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/new/targets.jam,v
retrieving revision 1.115
diff -u -r1.115 targets.jam
--- new/targets.jam 20 Aug 2003 21:56:49 -0000 1.115
+++ new/targets.jam 25 Aug 2003 23:00:21 -0000
@@ -505,8 +505,12 @@
p = [ $(p).expand-composites ] ;
p = [ $(p).add-defaults ] ;
local r = [ generate-really $(p) ] ;
- usage-requirements = [ $(usage-requirements).add $(r[1]) ] ;
- result += $(r[2-]) ;
+
+ if $(r)
+ {
+ usage-requirements = [ $(usage-requirements).add $(r[1]) ] ;
+ result += $(r[2-]) ;
+ }
}
end-building $(__name__) ;
return $(usage-requirements) $(result) ;

 --------------030602070803040002060509--