Boost logo

Boost-Build :

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.


 --------------030602070803040002060509 Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;

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) ;


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at