aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/config
AgeCommit message (Collapse)AuthorFilesLines
2022-06-06Add another config::origin() overloadBoris Kolpackov2-2/+15
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-03Move config::variable_visibility to separate types.hxx headerBoris Kolpackov2-8/+27
2022-05-23Add config::origin(const variable&) overloadBoris Kolpackov2-9/+23
2022-05-22Add support for variable patterns in config.config.disfigureBoris Kolpackov1-5/+116
2022-05-20Make $config.origin() also available internally as config::origin()Boris Kolpackov3-28/+59
2022-05-19Add config.config.unload variable to omit loading config.buildBoris Kolpackov1-7/+34
Note that the configuration is still loaded from config.config.load if specified. Note also that similar to config.config.load, only values specified on this project's root scope and global scope are considered.
2022-05-11Add $config.origin() functionBoris Kolpackov1-0/+70
This function can be used to query the origin of a configuration variable value. The result is one of `undefined`, `default`, `buildfile`, or `override`.
2022-04-19Switch to using std::function for target::data_padBoris Kolpackov2-3/+6
2022-04-07Rename {match,execute}() to *_sync(), add *_complete()Boris Kolpackov1-1/+1
In particular, the match() rename makes sure it doesn't clash with rule::match() which, after removal of the hint argument in simple_rule, has exactly the same signature, thus making it error-prone to calling recursively.
2022-04-06Add support for rule hintsBoris Kolpackov1-3/+2
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-29Add variable_map::lookup_namespace(string) overloadBoris Kolpackov3-8/+4
2022-03-23Add note on disfig.* variables ideaBoris Kolpackov1-0/+16
2022-03-23Clarify config::save_*_omitted semanticsBoris Kolpackov1-5/+12
2022-03-22Add ability to disfigure specific configuration variablesBoris Kolpackov1-0/+27
The new config.config.disfigure variable can be used to specify the list of variables to ignore when loading config.build (and any files specified in config.config.load), letting them to take on the default values. For example: $ b configure config.config.disfigure=config.hello.fancy
2022-02-16Invent quoting modes for to_stream(name)Karen Arutyunov1-3/+3
2021-12-16Pass context to (meta-)operation hooksBoris Kolpackov1-4/+4
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 Kolpackov4-24/+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-06-21Add support for automatic generation of symbol exporting .def fileBoris Kolpackov1-3/+1
2021-04-26Detect and diagnose presence of certain GCC environment variablesBoris Kolpackov1-7/+6
Their presence is incompatible with what we are doing.
2021-04-22Incorporate project environment checksum into cc::compiler_info cache keyBoris Kolpackov1-1/+7
2021-04-22Add another hash/save_environment() overloadBoris Kolpackov1-0/+10
2021-04-20Track changes to environment in cc rulesBoris Kolpackov1-1/+3
2021-04-09Fix bug in configure meta-operation implementationBoris Kolpackov1-1/+1
2021-04-07Register environment variables for hermetic build configurationsBoris Kolpackov5-2/+99
2021-04-04Add base functionality for hermetic build configurationshermeticBoris Kolpackov5-105/+325
2021-04-02Add support for propagating project environmentBoris Kolpackov1-2/+84
2021-03-26Implement config.config.environment storageBoris Kolpackov5-99/+252
2021-03-19Redo entering of src directories into scope_mapBoris Kolpackov1-4/+4
2021-02-08Enter scope src directories into scope mapBoris Kolpackov1-1/+1
2021-01-30Add std::{map, multimap} to types.hxxBoris Kolpackov2-5/+1
Seeing that std::map is becoming a common Buildfile variable type.
2020-12-04Mark Buildfile functions as pure or impureBoris Kolpackov1-1/+3
2020-12-02Fix bug in config utilityBoris Kolpackov1-2/+3
2020-09-24Give hints for common causes of "no rule to update ..." errorBoris Kolpackov1-1/+1
2020-09-24Add ability to ignore extra variables in specified_config()Boris Kolpackov2-9/+33
2020-08-18Add ability to mark config.* variables as "unsaved" (always transient)Boris Kolpackov5-19/+40
2020-08-16Add support for post-configure and pre-disfigure hooksBoris Kolpackov6-27/+121
2020-08-16Add ability to initialize bootstrapped modules after loading root.buildBoris Kolpackov1-2/+4
2020-07-12Cache subprojects variable value in scope::root_extraBoris Kolpackov1-8/+8
2020-07-02Optimize variable extraction in bootstrap_src()Boris Kolpackov1-4/+3
2020-06-12Make order of imports stable in saved host build configurationBoris Kolpackov1-4/+4
2020-06-05Add ability to specify ad hoc recipe actionsBoris Kolpackov1-1/+1
We are reusing the buildspec syntax for that.
2020-05-27Initial support for ad hoc recipes (still work in progress)Boris Kolpackov1-2/+2
2020-05-27Amalgamation cutoff supportBoris Kolpackov1-4/+2
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/+14
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-27Add utility config::{assign,append}_config() functionsBoris Kolpackov1-1/+43
2020-04-27Don't switch projects when switching scopes during bootstrapBoris Kolpackov1-1/+4
2020-04-08Document project-specific configuration supportBoris Kolpackov1-1/+1
2020-04-02Fix ~host config to only contain cc and bin modules configurationBoris Kolpackov2-3/+7
Also add ~build2 that contains everything (except config.dist.*) to be used for build system modules.