aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/scope.cxx
AgeCommit message (Collapse)AuthorFilesLines
2022-10-10Use term shared instead of global for scope, var pool, etcBoris Kolpackov1-3/+3
2022-05-06Minor terminology fix in diagnostics and commentsBoris Kolpackov1-1/+1
2022-03-11Add JSON format support for --structured-result option and info meta operationKaren Arutyunov1-1/+1
2021-09-15Do variable lookup in ad hoc target groupsBoris Kolpackov1-8/+25
2021-09-02Don't consider aliasing in variable override lookupBoris Kolpackov1-1/+5
2021-06-08Implement ad hoc regex pattern rule supportBoris Kolpackov1-17/+33
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-05-28Add support for regex-based target type/pattern specific variablesBoris Kolpackov1-4/+4
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-28Tie loose ends in target type/pattern-specific matchingBoris Kolpackov1-13/+22
2021-05-28Clean default target type extension logicBoris Kolpackov1-0/+38
2021-05-28Make notion of name pattern explicit, fix various related loose endsBoris Kolpackov1-23/+16
2021-03-19Redo entering of src directories into scope_mapBoris Kolpackov1-49/+69
2021-02-08Enter scope src directories into scope mapBoris Kolpackov1-13/+46
2020-11-12Assign fixed extensions to wasm{} and pdb{} target typesBoris Kolpackov1-0/+9
2020-07-12Cache subprojects variable value in scope::root_extraBoris Kolpackov1-0/+18
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov1-9/+43
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-03-31Switch to project variable visibility by defaultBoris Kolpackov1-2/+2
2020-03-19Tweak lookup_config() semantics some moreBoris Kolpackov1-7/+9
2020-03-17Rename all find*(variable) to lookup*(variable)Boris Kolpackov1-29/+29
Now we consistently use term "lookup" for variable value lookup. At some point we should also rename type lookup to binding and get rid of all the lookup_type aliases.
2020-02-07Drop copyright notice from source codeKaren Arutyunov1-1/+0
2019-10-22Move global mutex shards to contextBoris Kolpackov1-4/+6
2019-08-26Fix bug in scope::find_target_key()Boris Kolpackov1-1/+8
2019-08-26Suppress gcc's 'control reaches end of non-void function' warningKaren Arutyunov1-1/+1
2019-08-26Factor target name processing code from parser to scopeBoris Kolpackov1-0/+59
2019-08-26Make target types project-wideBoris Kolpackov1-26/+13
2019-08-23Introduce notion of build contextBoris Kolpackov1-19/+14
All non-const global state is now in class context and we can now have multiple independent builds going on at the same time.
2019-07-01Split build system into library and driverBoris Kolpackov1-0/+911