aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/parser.cxx
AgeCommit message (Collapse)AuthorFilesLines
2022-06-28Add support for rule-specific import phase 2Boris Kolpackov1-15/+44
For example: import! [metadata, rule_hint=cxx.link] lib = libhello%lib{hello}
2022-06-21Add --trace-{match,execute} optionsBoris Kolpackov1-32/+72
These options can be used to understand which dependency chain causes matching or execution of a particular target.
2022-06-03Reset value::extra on variable_map value change/version incrementBoris Kolpackov1-1/+1
The reset on each modification semantics is used to implement the default value distinction as currently done in the config module but later probably will be done for ?= and $origin().
2022-06-03Expose type name to value_type mapping function in parserBoris Kolpackov1-4/+4
2022-04-08Register ad hoc rules for configure in addition to distBoris Kolpackov1-8/+12
2022-04-06Add support for specifying custom ad hoc pattern rule namesBoris Kolpackov1-7/+53
Besides diagnostics, this allows us to use name in the rule hint, for example: [rule_name=hello.link] exe{~'/(.*)/'}: obje{~'/\1/'} {{ $cxx.path -o $path($>) $path($<[0]) }} [rule_hint=hello] exe{hello}: obje{hello} obje{hello}: c{hello-c}
2022-04-06Add support for rule hintsBoris Kolpackov1-14/+115
A rule hint is a target attribute, for example: [rule_hint=cxx] exe{hello}: c{hello} Rule hints can be used to resolve ambiguity when multiple rules match the same target as well as to override an unambiguous match.
2022-03-23Make project configuration variables non-nullable by defaultBoris Kolpackov1-4/+46
A project configuration variable with the NULL default value is naturally assumed nullable, for example: config [string] config.libhello.fallback_name ?= [null] Otherwise, to make a project configuration nullable we use the `null` variable attribute, for example: config [string, null] config.libhello.fallback_name ?= "World"
2022-02-21Ban module names that start with underscoreBoris Kolpackov1-0/+3
2022-02-16Invent quoting modes for to_stream(name)Karen Arutyunov1-1/+1
2022-02-14Add parser::parse_eval() public API functionBoris Kolpackov1-0/+44
2022-02-07Add support for meta-operation wildcard in scope::insert_rule()Boris Kolpackov1-0/+6
2022-01-06Add depdb-dyndep --update-{include,exclude} optionsBoris Kolpackov1-1/+2
These options specify prerequisite targets/patterns to include/exclude (from the static prerequisite set) for update during match as part of dynamic dependency extraction (those excluded will be updated during execute). For example: depdb dyndep ... --update-exclude libue{hello-meta} ... depdb dyndep ... --update-exclude libue{*} ... depdb dyndep ... --update-include $moc --update-include hxx{*} ... The order in which these options are specified is significant with the first target/pattern that matches determining the result. If only the --update-include options are specified, then only the explicitly included prerequisites will be updated. Otherwise, all prerequisites that are not explicitly excluded will be updated. If none of these options is specified, then all the static prerequisites are updated during match. Note also that these options do not apply to ad hoc prerequisites which are always updated during match.
2021-12-02Automatically register pattern rules for dist meta-operationBoris Kolpackov1-4/+28
We need to do this in order to inject additional pattern prerequisites which may "pull" additional sources into the distribution.
2021-10-14Add ability to detect sole expansion in parser::parse_names()Boris Kolpackov1-5/+12
2021-09-28Adapt to libbutl headers extension change from .mxx to .hxxKaren Arutyunov1-1/+1
2021-09-20Assign pre-defined semantics to config.<project>.develop variablesBoris Kolpackov1-20/+59
This variable allows a project to distinguish between development and consumption builds. While normally there is no distinction between these two modes, sometimes a project may need to provide additional functionality during development. For example, a source code generator which uses its own generated code in its implementation may need to provide a bootstrap step from the pre-generated code. Normally, such a step is only needed during development. See "Project Configuration" in the manual for details.
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