Re: [jamboost] [patch] Re: feature threading does not

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-08-29 03:46:14

Hi Christopher,

> 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 
anything.

- Volodya