| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It turns out that when propagating {c,cxx}.config in tests we don't want to
propagate any options (such as *.std) that have been folded into our project's
mode.
|
|
Before the block used to apply to the set of prerequisites before the last
`:`. This turned out to be counterintuitive and not very useful since
prerequisite-specific variables are a lot less common than target specific.
And it doesn't fit with ad hoc recipes.
The new rule is if the chain ends with `:`, then the block applies to the last
set of prerequisites. Otherwise, it applies to the last set of targets. For
example:
./: exe{test}: cxx{main}
{
test = true # Applies to the exe{test} target.
}
./: exe{test}: libue{test}:
{
bin.whole = false # Applies to the libue{test} prerequisite.
}
This is actually consistent with both non-chain and non-block cases.
Consider:
exe{test}: cxx{main}
{
test = true
}
exe{test}: libue{test}:
{
bin.whole = false
}
exe{test}: libue{test}: bin.whole = false
The only exception we now have in this overall approach of "if the
dependency declaration ends with a colon, then what follows is for a
prerequisite" is for the first semicolon:
exe{test}:
{
test = true
}
exe{test}: test = true
But that's probably intuitive enough since there cannot be a prerequisite
without a target.
|
|
Use this information to omit ad hoc C++ recipe tests is testing statically-
linked build system.
|
|
|
|
|
|
We are reusing the buildspec syntax for that.
|
|
|
|
Also deduce the recipe name.
|
|
This will allow us to deal with backward-incompatible changes to cxx_rule
interface and semantics.
|
|
|
