Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-11-18 13:23:42

On Thursday 16 November 2006 08:59, Rene Rivera wrote:
> Rene Rivera wrote:
> > I'll see how much farther I can get without using a rule.
> OK, I think the attached additional patch produces the
> desired/equivalent results (except for the warning messages). The
> root/Jamfile.v2 patch is just to show the other bits of code using this
> obsoletes.
> I tested (virtually) both doing builds, and running tests. In both cases
> targets that depended on ones with <build>no conditionally added to them
> where skipped. (AFAICT)

Apparently, I've managed to unintentionally modify the code so that if any
target has <build>no in requirements, it will return <build>no in the usage
requirements and all dependents won't be built.

That seemed like good thing to me until I though about this:

        install all : a b ;
        lib a ;
        lib b : ..... : <link>shared <runtime-link>static ;

In this case, not only 'b' won't be built, but also 'all' will be skipped,
and 'a' won't be installed. Does not seem a useful behaviour, but I'm not
sure how to make it useful.

Now that I think of it, I'm not sure if using toolset requirements is the
right mechanism to avoid building impossible combination -- after all, this
combination is impossible for a specific generator. I have a use case where
generator for some other toolset tries to build lib explicitly requesting gcc
toolset. In that case, main target won't have toolset=gcc in requirements,
but gcc generator still must fail.

In other words, we might need both the toolchain requirements you've added,
and the check inside the generator.

- Volodya

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