Potential problem with transitive <build>no about b2

[grafikrobot]

I would prefer option 3. It's the clearest behavior. Even if it's not the most convenient.

[pdimov]

The issue is that there's no reason why all alias targets (and only alias targets) should be excepted like that.

Well because alias targets won't fail if one of their dependencies doesn't build, whereas other targets will.

[grisumbras]

While all alias targets themselves don't fail if their sources are skipped, their dependent targets can. Consider this:

lib foo : foo.cpp : <build>no ;
alias bar : foo ;
exe baz : baz.cpp bar ;

All sources of target bar effectively become sources of target baz. But not directly, so baz won't be skipped.

That being said, option 3 is the most conservative behaviour, that creates least surprises.

[grisumbras]

Actually, I had a thought about approach number 4:

1. For alias targets do not skip the target due to <build>no in usage requirements.
2. For all targets add <build>no to usage requirements if there is <build>no in either requirements or usage requirements.

As as result the problematic case from the first post will be fixed (alias target will not be skipped, so all of its non-skipped explicit sources will be built). But also non-alias downstream targets will be skipped, so problematic case from previous post is fixed too. Furthermore we'll have a nice auto-skip for tests:

lib foo : foo.cpp : [ requires cxx11_feature ] ;
run test1  : test1.cpp foo ; # skipped on C++03