aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/scope.hxx
AgeCommit message (Collapse)AuthorFilesLines
2024-04-02Detect and diagnose attempt to create new target in src directoryBoris Kolpackov1-1/+7
GitHub issue #277.
2024-01-15Automatically alias unknown target types of imported targetsBoris Kolpackov1-4/+10
2024-01-15Fail with unable to import rather than unknown target typeBoris Kolpackov1-3/+9
2024-01-11Add ability to alias target type from another projectBoris Kolpackov1-1/+1
The syntax is: define <type> = <scope>/<type>
2024-01-08Improve documentation commentBoris Kolpackov1-2/+2
2023-05-29Explicit group: syntax parsingBoris Kolpackov1-1/+5
2023-04-19Fix several issues in build system module importation logicmodule-importBoris Kolpackov1-5/+6
2023-04-13Various minor generalizations for in-process configure support in bpkgBoris Kolpackov1-1/+1
2022-11-29Move buildfiles to root_extra, use vector instead of unordered_setBoris Kolpackov1-9/+19
2022-10-13Work around Clang 6, 7 codegen issuesBoris Kolpackov1-2/+3
2022-10-13Switch to public/private variables modelBoris Kolpackov1-21/+51
Now unqualified variables are project-private and can be typified.
2022-10-10Preparatory work for public/private variable distinctionBoris Kolpackov1-1/+14
We still always use the public var_pool from context but where required, all access now goes through scope::var_pool().
2022-10-10Use term shared instead of global for scope, var pool, etcBoris Kolpackov1-2/+2
2022-06-17Add ability to ignore subprojects in create_bootstrap_outer()Boris Kolpackov1-1/+1
2022-04-20Add explicit flag to more efficiently avoid repeated load_root() callsBoris Kolpackov1-1/+2
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
generated by cgit v1.1 at 2024-04-16 07:03:17 +0000