aboutsummaryrefslogtreecommitdiff
path: root/tests/dependency
AgeCommit message (Collapse)AuthorFilesLines
2022-07-07Use new cmdline type for canned command lines in {Build,Test}scriptBoris Kolpackov1-2/+2
2021-06-08Redo low verbosity diagnostic deduction to use scope instead of targetBoris Kolpackov1-45/+20
2021-06-08Implement ad hoc regex pattern rule supportBoris Kolpackov1-2/+20
An ad hoc pattern rule consists of a pattern that mimics a dependency declaration followed by one or more recipes. For example: exe{~'/(.*)/'}: cxx{~'/\1/'} {{ $cxx.path -o $path($>) $path($<[0]) }} If a pattern matches a dependency declaration of a target, then the recipe is used to perform the corresponding operation on this target. For example, the following dependency declaration matches the above pattern which means the rule's recipe will be used to update this target: exe{hello}: cxx{hello} While the following declarations do not match the above pattern: exe{hello}: c{hello} # Type mismatch. exe{hello}: cxx{howdy} # Name mismatch. On the left hand side of `:` in the pattern we can have a single target or an ad hoc target group. The single target or the first (primary) ad hoc group member must be a regex pattern (~). The rest of the ad hoc group members can be patterns or substitutions (^). For example: <exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'} {{ $cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0]) }} On the left hand side of `:` in the pattern we have prerequisites which can be patterns, substitutions, or non-patterns. For example: <exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'} hxx{^'/\1/'} hxx{common} {{ $cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0]) }} Substitutions on the left hand side of `:` and substitutions and non-patterns on the right hand side are added to the dependency declaration. For example, given the above rule and dependency declaration, the effective dependency is going to be: <exe{hello} file{hello.map>: cxx{hello} hxx{hello} hxx{common}
2021-06-08Only pass target to recipe_text() if recipe is not sharedBoris Kolpackov1-20/+45
2020-07-16Save original compiler path/mode in {c,cxx}.config.path/modeBoris Kolpackov1-1/+1
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.
2020-07-06Adjust variable block applicability in dependency chainsBoris Kolpackov2-0/+95
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.
2020-06-16Add metadata for exe{b}, including whether it is statically-linkedBoris Kolpackov1-0/+3
Use this information to omit ad hoc C++ recipe tests is testing statically- linked build system.
2020-06-10Add ad hoc recipe if-else, switch tests (and fix bug)Boris Kolpackov1-0/+149
2020-06-05Add depdb buildscript builtinKaren Arutyunov1-0/+1
2020-06-05Add ability to specify ad hoc recipe actionsBoris Kolpackov1-38/+70
We are reusing the buildspec syntax for that.
2020-06-04Properly handle diag directive in build script parserKaren Arutyunov1-3/+4
2020-06-03Allow process path values and targets as buildscript program namesKaren Arutyunov1-39/+297
Also deduce the recipe name.
2020-06-03Add versioning for ad hoc C++ recipesBoris Kolpackov1-2/+2
This will allow us to deal with backward-incompatible changes to cxx_rule interface and semantics.
2020-05-27Initial support for ad hoc recipes (still work in progress)Boris Kolpackov3-1/+349
2020-02-07Drop copyright notice from source codeKaren Arutyunov2-2/+0
2019-01-16Update copyright yearKaren Arutyunov2-2/+2
2018-11-16Implement support for dependency chainsBoris Kolpackov2-0/+44
Now instead of: ./: exe{foo} exe{foo}: cxx{*} We can write: ./: exe{foo}: cxx{*} Or even: ./: exe{foo}: libue{foo}: cxx{*} This can be combined with prerequisite-specific variables (which naturally only apply to the last set of prerequisites in the chain): ./: exe{foo}: libue{foo}: bin.whole = false