aboutsummaryrefslogtreecommitdiff
path: root/build2
AgeCommit message (Collapse)AuthorFilesLines
2020-12-08Regenerate options parsing codeKaren Arutyunov1-1/+17
2020-12-08Add --options-file optionKaren Arutyunov5-1/+76
2020-09-22Add ability to skip external modules during bootstrap (--no-external-modules)Boris Kolpackov5-0/+33
2020-09-22Add note about non-global variable overridesBoris Kolpackov1-0/+5
2020-09-17Add support for BUILD2_VAR_OVR and BUILD2_DEF_OPT environment variablesKaren Arutyunov3-33/+172
2020-09-12Regenerate options parsing codeKaren Arutyunov1-9/+9
2020-09-11Add support for default global variable overridesKaren Arutyunov3-6/+47
2020-09-09Fix formatting in man pageBoris Kolpackov2-4/+4
2020-08-16Redo modules map as vectorBoris Kolpackov1-10/+10
2020-07-13Add ability to extend rule interface in source-compatible mannerBoris Kolpackov1-1/+1
2020-07-12Cache subprojects variable value in scope::root_extraBoris Kolpackov1-2/+2
2020-07-10Fix bugBoris Kolpackov1-1/+1
2020-07-09Load test and install modules implicitly for simple projectsBoris Kolpackov1-0/+10
While these can be useful on their own, this also makes the test and install operations available in simple projects, which is handy for "glue" projects that "pull" (using ad hoc import) a bunch of other projects.
2020-07-09Add support for ad hoc importationBoris Kolpackov1-97/+23
2020-06-16Add metadata for exe{b}, including whether it is statically-linkedBoris Kolpackov6-14/+88
Use this information to omit ad hoc C++ recipe tests is testing statically- linked build system.
2020-06-12Make order of imports stable in saved host build configurationBoris Kolpackov1-1/+3
2020-06-05Add ability to specify ad hoc recipe actionsBoris Kolpackov2-3/+4
We are reusing the buildspec syntax for that.
2020-05-28Regenerate options parsing codeBoris Kolpackov1-39/+40
2020-05-27Initial support for ad hoc recipes (still work in progress)Boris Kolpackov2-2/+3
2020-05-27Amalgamation cutoff supportBoris Kolpackov1-2/+2
Now a project that disables amalgamation will not logically "see" an outer project even if it's physically inside its scope.
2020-04-30Verify path set by {src,out}-root.build files is absoluteBoris Kolpackov1-3/+1
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov6-283/+231
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 Kolpackov2-8/+6
2020-03-30Regenerate options parsing codeBoris Kolpackov2-6/+55
2020-03-17Rework config::{omitted,required,optional}() into unified config_lookup()Boris Kolpackov1-19/+20
2020-03-11Minor config variable lookup cleanupsBoris Kolpackov1-3/+3
2020-02-18Fix copyright notice extraction for building and documentation generatingKaren Arutyunov1-4/+5
2020-02-12Use copyright extracted from COPYRIGHT file for printing build2 versionKaren Arutyunov2-3/+15
2020-02-11Add match_only flag to contextBoris Kolpackov1-3/+4
2020-02-07Drop copyright notice from source codeKaren Arutyunov11-11/+0
2020-01-29Rename module_base to module, redo module boot/init argument passingBoris Kolpackov1-7/+3
2020-01-28Use scope::var_pool()Boris Kolpackov1-7/+7
2020-01-28Use scope::insert_rule()Boris Kolpackov1-8/+6
2020-01-27Improve module loading APIBoris Kolpackov1-1/+1
2019-11-26Use switch in buildfileKaren Arutyunov1-14/+12
2019-11-15Use path_name_view in location and path_name_value in location_valueKaren Arutyunov1-1/+1
2019-11-11Use path_name for `-` to stdin/stdout translationKaren Arutyunov1-1/+1
2019-11-04Add support for configuration exporting and importingBoris Kolpackov1-1/+1
The new config.export variable specifies the alternative file to write the configuration to as part of the configure meta-operation. For example: $ b configure: proj/ config.export=proj-config.build The config.export value "applies" only to the projects on whose root scope it is specified or if it is a global override (the latter is a bit iffy but we allow it, for example, to dump everything to stdout). This means that in order to save a subproject's configuration we will have to use a scope-specific override (since the default will apply to the outermost amalgamation). For example: $ b configure: subproj/ subproj/config.export=.../subproj-config.build This could be somewhat unnatural but then it will be the amalgamation whose configuration we normally want to export. The new config.import variable specifies additional configuration files to be loaded after the project's default config.build, if any. For example: $ b create: cfg/,cc config.import=my-config.build Similar to config.export, the config.import value "applies" only to the project on whose root scope it is specified or if it is a global override. This allows the use of the standard override "positioning" machinery (i.e., where the override applies) to decide where the extra configuration files are loaded. The resulting semantics is quite natural and consistent with command line variable overrides, for example: $ b config.import=.../config.build # outermost amalgamation $ b ./config.import=.../config.build # this project $ b !config.import=.../config.build # every project Both config.export and config.import recognize the special `-` file name as an instruction to write/read to/from stdout/stdin, respectively. For example: $ b configure: src-prj/ config.export=- | b configure: dst-prj/ config.import=-
2019-10-29Only use -rdynamic (for backtrace support) on Linux if using glibcBoris Kolpackov1-1/+2
2019-10-29Regenerate options parsing codeBoris Kolpackov1-7/+37
2019-10-28Document default options filesBoris Kolpackov1-8/+40
2019-10-25Add --silent, remap verbosity 0 to 1 while building modules unless silentBoris Kolpackov5-16/+59
Failed that, we may have long periods of seemingly nothing happening (e.g., during implicit bdep sync) while we quietly update the module, which may look like things have hung up.
2019-10-22Add load_builtin_module()Boris Kolpackov1-21/+13
2019-10-22Rename global_mutex_shards to global_mutexesBoris Kolpackov1-3/+3
2019-10-22Move global mutex shards to contextBoris Kolpackov1-15/+12
2019-10-14Implement MSVC installation discovery for version 15 (2017) and laterKaren Arutyunov1-1/+1
In particular, this removes the requirement to build from the Visual Studio command prompt. Note that since MSVC compiler binaries are target-specific (i.e., there are no -m32/-m64 options nor something like /MACHINE), in this case we default to a 64-bit build (a 32-bit build can still be achieved by running from a suitable command prompt). Finally, this mechanism is also used to find Clang bundled with MSVC.
2019-10-06Adapt for building with Clang on WindowsKaren Arutyunov1-2/+2
2019-08-28Cleanup buildfiles some moreBoris Kolpackov1-29/+4
2019-08-28Add build2_cli_load()Karen Arutyunov3-26/+26
2019-08-28Move cxx build system module to separate libraryKaren Arutyunov8-856/+5