Age | Commit message (Collapse) | Author | Files | Lines | |
---|---|---|---|---|---|
2022-10-11 | Factor variable patterns out of variable_pool into separate variable_patterns | Boris Kolpackov | 1 | -0/+1 | |
We have patterns only for the public variables pool. | |||||
2021-11-03 | Add line processing customization hook to in::rule | Boris Kolpackov | 1 | -0/+4 | |
2021-06-08 | Implement ad hoc regex pattern rule support | Boris Kolpackov | 1 | -0/+1 | |
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} | |||||
2020-11-11 | Expose low-level function registration support | Boris Kolpackov | 1 | -0/+1 | |
2020-10-20 | Add operation callback for adhoc rule match and apply | Boris Kolpackov | 1 | -0/+2 | |
2020-06-05 | Add ability to specify ad hoc recipe actions | Boris Kolpackov | 1 | -1/+1 | |
We are reusing the buildspec syntax for that. | |||||
2020-06-03 | Factor implementation-specific ad hoc recipe parsing to adhoc_*_rule | Boris Kolpackov | 1 | -0/+5 | |
2020-04-27 | Rework tool importation along with cli module | Boris Kolpackov | 1 | -1/+4 | |
Specifically, now config.<tool> (like config.cli) is handled by the import machinery (it is like a shorter alias for config.import.<tool>.<tool>.exe that we already had). And the cli module now uses that instead of custom logic. This also adds support for uniform tool metadata extraction that is handled by the import machinery. As a result, a tool that follows the "build2 way" can be imported with metadata by the buildfile and/or corresponding module without any tool-specific code or brittleness associated with parsing --version or similar outputs. See the cli tool/module for details. Finally, two new flavors of the import directive are now supported: import! triggers immediate importation skipping any rule-specific logic while import? is optional import (analogous to using?). Note that optional import is always immediate. There is also the import-specific metadata attribute which can be specified for these two import flavors in order to trigger metadata importation. For example: import? [metadata] cli = cli%exe{cli} if ($cli != [null]) info "cli version $($cli:cli.version)" | |||||
2020-02-07 | Drop copyright notice from source code | Karen Arutyunov | 1 | -1/+0 | |
2019-10-29 | Add forward declaration header for build state types | Boris Kolpackov | 1 | -0/+73 | |