aboutsummaryrefslogtreecommitdiff
path: root/tests/dependency/recipe
AgeCommit message (Collapse)AuthorFilesLines
2024-02-12Add ability to specify recipes in separate filesBoris Kolpackov1-1/+1
This can now be achieved with the new `recipe` directive: recipe <language> <file> Note that similar to the use of if-else and switch directives with recipes, this directive requires explicit % recipe header. For example, instead of: file{foo.output}: {{ echo 'hello' >$path($>) }} We can now write: file{foo.output}: % recipe buildscript hello.buildscript With hello.buildscript containing: echo 'hello' >$path($>) Similarly, for C++ recipes (this time for a pattern), instead of: [rule_name=hello] file{~'/(.+)\.output/'}: % update clean {{ c++ 1 -- -- ... }} We can now write: [rule_name=hello] file{~'/(.+)\.output/'}: % update clean recipe c++ hello.cxx With hello.cxx containing: // c++ 1 -- -- ... Relative <file> paths are resolved using the buildfile directory that contains the `recipe` directive as a base. Note also that this mechanism can be used in exported buildfiles with recipe files placed into build/export/ together with buildfiles.
2022-11-25Use operation name as a buildscript name if unable to deduceKaren Arutyunov1-12/+36
2022-10-18Invent diag preamble for buildscriptKaren Arutyunov1-1/+4
2022-07-08Fix some tests to match canned command line semanticsKaren Arutyunov1-1/+1
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 Kolpackov1-0/+46
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 Kolpackov2-0/+348