From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-29 03:46:14
> 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 ;
Thanks for spotting this bug.
> 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.
I've applied a somewhat different patch (attached to this email). Instread of
checking what generate-really returned, I document what it should return and
make it always return what's documented.
> 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?
That's a good question. I'm fretted by the current behaviour myself: in my
project some (small) part uses threads and refuses to build with simple
"bjam" invocation. Of course, I don't want to run "bjam threading=multi" from
the top, since other parts don't need threading at all.
> * 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.
Yep, the double time/space requirements are not nice.
> 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.
This is the question! Another question: should any feature be
link-incompatible? And another note: shouldn't link-incompatibility checks be
made only when one target uses (has as dependency) another one? With the
current arrangement, if you specify threading=single, no target can be built
with threading=multi, even if the target is standalone binary, not linked to
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