aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/parser.cxx
AgeCommit message (Collapse)AuthorFilesLines
2021-08-09Use parse_variable_name() in parse_import(), parse_config()Boris Kolpackov1-15/+19
2021-08-09Make variable assignment mandatory in import directiveBoris Kolpackov1-125/+52
In return we get the ability to specify value attributes.
2021-08-04Take into account file-base'ness in ad hoc buildscript recipesBoris Kolpackov1-3/+9
2021-07-23Reserve variable names/components that start with underscore to build2 coreBoris Kolpackov1-2/+28
2021-06-08Redo low verbosity diagnostic deduction to use scope instead of targetBoris Kolpackov1-8/+2
2021-06-08Get rid of special *{} wildcard target type notation in target type/patternsBoris Kolpackov1-17/+6
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-189/+600
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-3/+9
2021-05-28Add support for regex-based target type/pattern specific variablesBoris Kolpackov1-155/+293
This is in addition to the already supported path-based target type/pattern specific variables. For example: hxx{*}: x = y # path-based hxx{~/.*/}: x = y # regex-based
2021-05-28Recognize quoting of first character in tokenBoris Kolpackov1-18/+30
Use this to relax the pattern inclusion/exclusion syntax to only require unquoted +/-.
2021-05-28Add pattern_mode::ignore and use in appropriate placesBoris Kolpackov1-15/+24
2021-05-28Make notion of name pattern explicit, fix various related loose endsBoris Kolpackov1-85/+178
2021-05-03Allow unseparated scope-qualified variable assignment and expansionBoris Kolpackov1-6/+41
2021-04-09Document hermetic build configuration supportBoris Kolpackov1-0/+4
2021-04-07Register environment variables for hermetic build configurationsBoris Kolpackov1-0/+46
2021-04-02Add support for propagating project environmentBoris Kolpackov1-14/+30
2021-01-30Rework include translation supportBoris Kolpackov1-1/+0
See the config.cxx.translate_include variable documentation in cxx/init.cxx for details.
2021-01-30Take advantage of small std::function optimizationBoris Kolpackov1-8/+13
2021-01-12Diagnose typed and project-qualified empty namesBoris Kolpackov1-28/+63
2020-12-08In update ad hoc recipe buildscripts allow non-pure function calls only in ↵Karen Arutyunov1-0/+8
depdeb preamble
2020-12-02Add support for buildscript depdb preambleKaren Arutyunov1-11/+14
2020-11-17Generalize dot escaping in target name rulesBoris Kolpackov1-1/+1
Now triple dot and escape sequence can appear almost anywhere in the target name (see target::split_name() for details).
2020-09-24Give hints for common causes of "no rule to update ..." errorBoris Kolpackov1-13/+14
2020-08-12Add int64 and int64s variable typesBoris Kolpackov1-0/+2
2020-07-14Recognize `build2` as special module name in addition to `build`Boris Kolpackov1-2/+2
This is for consistency with version constraints in manifest.
2020-07-13Fix version check in using directiveBoris Kolpackov1-8/+9
2020-07-13Reserve backtick (`) and bit-or (|) in eval context for future useBoris Kolpackov1-0/+8
Specifically, they are reserved for future support of arithmetic evaluation contexts and evaluation pipelines, respectively.
2020-07-12Rename rule-adhoc-* to adhoc-rule-*Boris Kolpackov1-2/+2
2020-07-09Add support for ad hoc importationBoris Kolpackov1-3/+8
2020-07-06Adjust variable block applicability in dependency chainsBoris Kolpackov1-106/+122
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-18Delay checking for ad hoc C++ recipe support until matchBoris Kolpackov1-9/+1
2020-06-15Diagnose building of module or ad hoc C++ recipe using static build systemBoris Kolpackov1-2/+6
2020-06-11Diagnose use of ad hoc C++ recipes with bootstrap build systemBoris Kolpackov1-1/+5
2020-06-10Add ad hoc recipe if-else, switch tests (and fix bug)Boris Kolpackov1-4/+10
2020-06-10Handle special variable names when spelled as $(<char>) rather than $<char>Boris Kolpackov1-2/+41
2020-06-10Fix bug in subscript of NULL valuesBoris Kolpackov1-1/+3
2020-06-09Factor ad hoc C++ and Buildscript rules into separate filesBoris Kolpackov1-1/+4
2020-06-05Add depdb buildscript builtinKaren Arutyunov1-1/+1
2020-06-05Add ability to split ad hoc C++ recipe into global and local fragmentsBoris Kolpackov1-6/+34
Specifically, now we can write: {{ c++ 1 -- #include <map> -- recipe apply (action, target&) const override { ... } }}
2020-06-05Add ability to specify ad hoc recipe actionsBoris Kolpackov1-8/+122
We are reusing the buildspec syntax for that.
2020-06-04Properly handle diag directive in build script parserKaren Arutyunov1-1/+2
2020-06-03Allow process path values and targets as buildscript program namesKaren Arutyunov1-2/+2
Also deduce the recipe name.
2020-06-03Add versioning for ad hoc C++ recipesBoris Kolpackov1-2/+21
This will allow us to deal with backward-incompatible changes to cxx_rule interface and semantics.
2020-06-03Factor implementation-specific ad hoc recipe parsing to adhoc_*_ruleBoris Kolpackov1-68/+40
2020-05-29Move low-verbosity command name from adhoc_script_rule to scriptBoris Kolpackov1-3/+3
2020-05-29Add support for is-else, switch in ad hoc recipesBoris Kolpackov1-130/+262
2020-05-27Add support for value subscript after expansionsBoris Kolpackov1-27/+118
Value subscript is only recognized in evaluation contexts (due to ambiguity with wildcard patterns; consider: $x[123].txt) and should be unseparated from the previous token. For example: x = ($y[1]) x = (($f ? $y : $z)[1]) x = ($identity($y)[$z])
2020-05-27Initial support for ad hoc recipes (still work in progress)Boris Kolpackov1-140/+404
2020-05-27Improve ternary diagnostics with info for wildcard pattern escapeBoris Kolpackov1-2/+13
2020-05-01Fix outstanding issue with directive vs assignment differentiationBoris Kolpackov1-6/+14
Specifically, now the following does the right thing: print +foo
generated by cgit v1.1 at 2024-11-01 19:24:03 +0000