aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/adhoc-rule-regex-pattern.cxx
AgeCommit message (Collapse)AuthorFilesLines
2023-05-29Avoid group linkup deadlocks for dynamic and pattern-static membersBoris Kolpackov1-13/+23
2023-05-29Explicit group: pattern membersBoris Kolpackov1-9/+84
2023-05-29Explicit group: static membersBoris Kolpackov1-4/+19
2022-04-20Replace match_extra::buffer with more general data storage facilityBoris Kolpackov1-4/+11
2022-04-19Use target recipe for auxiliary data storage during match-applyBoris Kolpackov1-4/+4
In particular, we now have separate auxiliary data storage for inner and outer operations.
2022-04-19Switch to using std::function for target::data_padBoris Kolpackov1-3/+0
2022-03-07Add support for update=unmatch|match to ad hoc recipesBoris Kolpackov1-22/+16
2022-01-06Factor reusable code to target_key::effective_name()Boris Kolpackov1-14/+5
2021-09-28Adapt to libbutl headers extension change from .mxx to .hxxKaren Arutyunov1-1/+1
2021-09-20Add support for disabling clean through target-prerequisite relationshipBoris Kolpackov1-1/+2
Our current semantics is to clean any prerequisites that are in the same project (root scope) as the target and it may seem more natural to rather only clean prerequisites that are in the same base scope. While it's often true for simple projects, in more complex cases it's not unusual to have common intermediate build results (object files, utility libraries, etc) reside in the parent and/or sibling directories. With such arrangements, cleaning only in base (even from the project root) may leave such intermediate build results laying around (since there is no reason to list them as prerequisites of any directory aliases). So we clean in the root scope by default but now any target-prerequisite relationship can be marked not to trigger a clean with the clean=false prerequisite-specific value.
2021-06-08Get rid of special *{} wildcard target type notation in target type/patternsBoris Kolpackov1-3/+1
Explicit target{} should be used instead. Also, in this context, absent target type is now treated as file{} rather than target{}, for consistency with all other cases.
2021-06-08Implement ad hoc regex pattern rule supportBoris Kolpackov1-0/+442
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}