aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/scope.hxx
AgeCommit message (Collapse)AuthorFilesLines
2022-04-19Switch to using std::function for target::data_padBoris Kolpackov1-0/+7
2022-04-15Omit unnecessary clearing of cached base_scope valuesBoris Kolpackov1-1/+1
2022-04-06Add support for rule hintsBoris Kolpackov1-3/+3
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-11Add JSON format support for --structured-result option and info meta operationKaren Arutyunov1-1/+5
2022-02-10Reorder inline function definition to help with MinGW GCC symbol exportBoris Kolpackov1-28/+1
2022-02-09Fix issue with implicit size_t to meta_operation_id conversionBoris Kolpackov1-9/+13
2022-02-07Add support for meta-operation wildcard in scope::insert_rule()Boris Kolpackov1-1/+25
2021-09-29Add notion of bundle amalgamation scopeBoris Kolpackov1-0/+9
2021-09-15Do variable lookup in ad hoc target groupsBoris Kolpackov1-1/+2
2021-06-08Implement ad hoc regex pattern rule supportBoris Kolpackov1-8/+12
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-28Tie loose ends in target type/pattern-specific matchingBoris Kolpackov1-13/+25
2021-05-28Make notion of name pattern explicit, fix various related loose endsBoris Kolpackov1-0/+4
2021-04-22Incorporate project environment checksum into cc::compiler_info cache keyBoris Kolpackov1-0/+6
2021-04-02Add support for propagating project environmentBoris Kolpackov1-0/+30
2021-03-19Redo entering of src directories into scope_mapBoris Kolpackov1-40/+55
2021-02-08Enter scope src directories into scope mapBoris Kolpackov1-9/+48
2021-02-03Propagate relevant options/prerequisites to header unit sidebuildsBoris Kolpackov1-3/+11
2021-01-30Add std::{map, multimap} to types.hxxBoris Kolpackov1-4/+2
Seeing that std::map is becoming a common Buildfile variable type.
2020-11-12Assign fixed extensions to wasm{} and pdb{} target typesBoris Kolpackov1-0/+5
2020-07-12Cache subprojects variable value in scope::root_extraBoris Kolpackov1-0/+11
2020-07-09Get rid of no longer needed friendBoris Kolpackov1-4/+0
2020-07-02Cache project name in root_extraBoris Kolpackov1-0/+12
2020-06-09Move recipe build directory to build/build/recipes/Boris Kolpackov1-2/+3
Our new scheme is to have any "out" content in a subdirectory called build/ (build/build/ for the build system core, build/<module>/build/ for modules). This way we can ignore them in .gitignore with a generic entry.
2020-05-27Amalgamation cutoff supportBoris Kolpackov1-5/+21
Now a project that disables amalgamation will not logically "see" an outer project even if it's physically inside its scope.
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov1-0/+21
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-04-27Require explicit variable type in scope::{assign,append}()Boris Kolpackov1-26/+39
2020-03-31Switch to project variable visibility by defaultBoris Kolpackov1-1/+19
2020-03-27Implement project configuration reporting, similar to build system modulesBoris Kolpackov1-0/+6
2020-03-20Initial implementation of config directive for project-specific configurationBoris Kolpackov1-6/+6
2020-03-19Tweak lookup_config() semantics some moreBoris Kolpackov1-2/+22
2020-03-17Rename all find*(variable) to lookup*(variable)Boris Kolpackov1-24/+26
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
2020-01-29Rename module_base to module, redo module boot/init argument passingBoris Kolpackov1-1/+1
2020-01-28Use scope::var_pool()Boris Kolpackov1-2/+2
2020-01-27See through lib{} group during distBoris Kolpackov1-0/+6
2020-01-27Add scope::{insert_rule,var_pool}() convenience functionsBoris Kolpackov1-2/+32
2019-11-14Make use of butl::to_stream(ostream, path, bool)Karen Arutyunov1-1/+3
2019-11-04Add $config.export() functionBoris Kolpackov1-4/+4
This is similar to the config.export variable functionality except it can be called from within buildfiles. Note that this function can only be used during configure unless the config module creation was forced for other meta-operations with config.module=true in bootstrap.build.
2019-10-29Add forward declaration header for build state typesBoris Kolpackov1-0/+1
2019-08-26Factor target name processing code from parser to scopeBoris Kolpackov1-0/+21
2019-08-26Make target types project-wideBoris Kolpackov1-6/+41
2019-08-23Introduce notion of build contextBoris Kolpackov1-40/+24
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-08-21Cleanup context.hxx and its usageBoris Kolpackov1-2/+25
2019-08-21Implement dynamic loading of build system modulesBoris Kolpackov1-1/+1
2019-07-02Minor improvementsBoris Kolpackov1-1/+1
2019-07-01Split build system into library and driverBoris Kolpackov1-0/+471
generated by cgit v1.1 at 2024-11-17 12:48:43 +0000