aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/config/utility.hxx
AgeCommit message (Collapse)AuthorFilesLines
2024-11-20Generalize config::specified_config()Boris Kolpackov1-6/+12
2024-10-08Expose custom save function in config moduleBoris Kolpackov1-14/+44
It can generally be useful, for example, to complete relative paths before saving them to config.build (if abs_dir_path does not fit).
2022-10-13Optimize by going straight to public variable pool where applicableBoris Kolpackov1-2/+2
2022-10-10Preparatory work for public/private variable distinctionBoris Kolpackov1-0/+8
We still always use the public var_pool from context but where required, all access now goes through scope::var_pool().
2022-06-14Tighten value::extra usage in config moduleBoris Kolpackov1-0/+5
Specifically, only values marked with 1 are treated as default leaving other values for use for other purposes.
2022-06-06Add another config::origin() overloadBoris Kolpackov1-0/+8
2022-06-03Move config::variable_visibility to separate types.hxx headerBoris Kolpackov1-8/+2
2022-05-23Add config::origin(const variable&) overloadBoris Kolpackov1-0/+3
2022-05-20Make $config.origin() also available internally as config::origin()Boris Kolpackov1-0/+16
2022-03-23Clarify config::save_*_omitted semanticsBoris Kolpackov1-5/+12
2021-09-20Assign pre-defined semantics to config.<project>.develop variablesBoris Kolpackov1-12/+25
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-04-26Detect and diagnose presence of certain GCC environment variablesBoris Kolpackov1-7/+6
Their presence is incompatible with what we are doing.
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-07Register environment variables for hermetic build configurationsBoris Kolpackov1-2/+81
2021-03-26Implement config.config.environment storageBoris Kolpackov1-0/+2
2020-09-24Add ability to ignore extra variables in specified_config()Boris Kolpackov1-2/+12
2020-08-18Add ability to mark config.* variables as "unsaved" (always transient)Boris Kolpackov1-1/+13
2020-08-16Add support for post-configure and pre-disfigure hooksBoris Kolpackov1-7/+40
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-08Document project-specific configuration supportBoris Kolpackov1-1/+1
2020-03-31Handle duplicate config directives for same variableBoris Kolpackov1-1/+2
2020-03-27Implement project configuration reporting, similar to build system modulesBoris Kolpackov1-2/+2
2020-03-19Tweak lookup_config() semantics some moreBoris Kolpackov1-3/+11
2020-03-17Rework config::{omitted,required,optional}() into unified config_lookup()Boris Kolpackov1-79/+148
2020-03-13Cleanup and make config/utility.?xx part of build system coreBoris Kolpackov1-40/+66
2020-03-11Minor config variable lookup cleanupsBoris Kolpackov1-28/+30
2020-02-07Drop copyright notice from source codeKaren Arutyunov1-1/+0
2020-01-27Fix typoBoris Kolpackov1-1/+1
2019-11-12Infra work for customizable config var persistence (config.config.persist)Boris Kolpackov1-0/+1
2019-10-29Add forward declaration header for build state typesBoris Kolpackov1-2/+1
2019-10-18Optimize config::required() to move default value if possibleBoris Kolpackov1-4/+7
2019-08-23Introduce notion of build contextBoris Kolpackov1-3/+3
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-24Use CLI-generated classes to parse testscript builtin optionsKaren Arutyunov1-1/+1
2019-07-05Move config, dist, test, and install modules into libraryKaren Arutyunov1-0/+179