aboutsummaryrefslogtreecommitdiff
path: root/doc/manual.cli
AgeCommit message (Collapse)AuthorFilesLines
2022-04-06Add support for rule hintsBoris Kolpackov1-0/+11
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-28Add ability to customize pkg-config header and library search pathsBoris Kolpackov1-6/+27
Specifically, {cc,c,cxx}.pkgconfig.{include,lib} variables specify header (-I) and library (-L) search paths to use in the generated .pc files instead of the default install.{include,lib}. Relative paths are resolved as install paths.
2022-03-23Document config.config.disfigureBoris Kolpackov1-1/+19
2022-03-23Make project configuration variables non-nullable by defaultBoris Kolpackov1-11/+20
A project configuration variable with the NULL default value is naturally assumed nullable, for example: config [string] config.libhello.fallback_name ?= [null] Otherwise, to make a project configuration nullable we use the `null` variable attribute, for example: config [string, null] config.libhello.fallback_name ?= "World"
2022-03-10Update manual to match new header pre-generation functionalityBoris Kolpackov1-25/+22
2022-02-24Add note on disabling subprojects/amalgamations import searchBoris Kolpackov1-0/+10
2022-01-26Make bash module install into bin/<project>.bash/ to avoid clashesBoris Kolpackov1-12/+15
Also, expect the first component in the import path to be full project name even in case it has the .bash extension.
2022-01-16Expand on extension escaping in manualBoris Kolpackov1-2/+8
2022-01-16Minor clarifications to wildcard name patterns section in manualBoris Kolpackov1-7/+16
2021-10-27Handle "common symbols" in symbol exporting .def generation ruleBoris Kolpackov1-2/+2
2021-10-26Minor documentation tweakBoris Kolpackov1-6/+6
2021-10-15Fix symbol exporting example in manualBoris Kolpackov1-1/+3
2021-10-14Move symbol exporting documentation from NEWS to manualBoris Kolpackov1-0/+46
2021-10-14Rearrange internal scope documentation, add note in target importBoris Kolpackov1-147/+149
2021-10-12Documentation fixesFrancois Kritzinger1-6/+6
2021-10-11Update bin.lib.version documentationBoris Kolpackov1-10/+10
2021-10-08Add few notes to internal scope documentationBoris Kolpackov1-6/+18
2021-10-05Add note to internal scope documentationBoris Kolpackov1-0/+19
2021-10-04Document internal scope functionalityBoris Kolpackov1-0/+125
2021-09-20Assign pre-defined semantics to config.<project>.develop variablesBoris Kolpackov1-0/+33
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-05-04Add config.install.root with data_root/etc/ defaultBoris Kolpackov1-0/+2
2021-04-22Add <version> install directory substitution in addition to <project>Boris Kolpackov1-3/+3
2021-04-22Document use of depdb-env for manually tracking changes to environmentBoris Kolpackov1-0/+18
2021-04-09Document hermetic build configuration supportBoris Kolpackov1-15/+183
2021-01-30Rework include translation supportBoris Kolpackov1-2/+2
See the config.cxx.translate_include variable documentation in cxx/init.cxx for details.
2020-12-08Add support for config.test.runnerKaren Arutyunov1-0/+32
2020-11-23Document include and source directivesBoris Kolpackov1-1/+32
2020-11-06Add support for test timeoutsKaren Arutyunov1-0/+22
2020-10-18Make some documentation fixesFrancois Kritzinger1-64/+65
2020-10-15Add ability to specify fallback value for NULL substitutions with in.nullBoris Kolpackov1-0/+13
2020-09-29Remove stray text from manualBoris Kolpackov1-3/+0
2020-09-24Fix typo in manualBoris Kolpackov1-1/+1
2020-08-12Add int64 and int64s variable typesBoris Kolpackov1-0/+3
2020-07-18Minor fix in manualBoris Kolpackov1-2/+2
2020-07-17Minor documentation updatesBoris Kolpackov1-2/+13
2020-07-16Documentation updatesBoris Kolpackov1-22/+40
2020-07-14Add another note on wildcards inside eval contextBoris Kolpackov1-3/+15
2020-07-13Document value subscriptsBoris Kolpackov1-3/+15
2020-07-13Reserve backtick (`) and bit-or (|) in eval context for future useBoris Kolpackov1-1/+5
Specifically, they are reserved for future support of arithmetic evaluation contexts and evaluation pipelines, respectively.
2020-07-10Document ad hoc import and its usage in glue buildfilesBoris Kolpackov1-11/+89
If the target being imported has no project name and is either absolute or is a relative directory, then this is treated as ad hoc importation. Semantically it is similar to a normal import but with the location of the project being imported hard-coded into the buildfile. This type of import can be used to create a special "glue buildfile" that "pulls" together several projects, usually for convenience of development. One typical case that calls for such a glue buildfile is a multi-package project. To be able to invoke the build system driver directly in the project root, we can add a glue buildfile that imports and builds all the packages: import pkgs = */ ./: $pkgs See "Target Importation" in the manual for details.
2020-07-10Add support for project-local importationBoris Kolpackov1-0/+28
An import without a project name or with the same name as the importing project's is now treated as importation from the same project. For example, given the libhello project that exports the lib{hello} target, a buildfile for an executable in the same project instead of doing something like this: include ../libhello/ exe{hello}: ../libhello/lib{hello} Can now do this: import lib = libhello%lib{hello} Or: import lib = lib{hello} And then: exe{hello}: $lib Note that a target in project-local importation must still be exported in the project's export stub. In other words, project-local importation goes through the same mechanisms as normal import.
2020-07-06Adjust variable block applicability in dependency chainsBoris Kolpackov1-3/+9
Before the block used to apply to the set of prerequisites before the last `:`. This turned out to be counterintuitive and not very useful since prerequisite-specific variables are a lot less common than target specific. And it doesn't fit with ad hoc recipes. The new rule is if the chain ends with `:`, then the block applies to the last set of prerequisites. Otherwise, it applies to the last set of targets. For example: ./: exe{test}: cxx{main} { test = true # Applies to the exe{test} target. } ./: exe{test}: libue{test}: { bin.whole = false # Applies to the libue{test} prerequisite. } This is actually consistent with both non-chain and non-block cases. Consider: exe{test}: cxx{main} { test = true } exe{test}: libue{test}: { bin.whole = false } exe{test}: libue{test}: bin.whole = false The only exception we now have in this overall approach of "if the dependency declaration ends with a colon, then what follows is for a prerequisite" is for the first semicolon: exe{test}: { test = true } exe{test}: test = true But that's probably intuitive enough since there cannot be a prerequisite without a target.
2020-07-02Use consistent style when referencing modules in manualBoris Kolpackov1-12/+13
2020-07-02Document private installation subdirectory mechanismBoris Kolpackov1-5/+76
A private installation subdirectory can be used to hide the implementation details of a project. This is primarily useful when installing an executable that depends on a bunch of libraries into a shared location, such as /usr/local/.
2020-06-29Add config.install.share variableBoris Kolpackov1-3/+4
Its default value is data_root/share/ and it is now used as a common root for config.install.{data,doc,man} variables.
2020-06-29Add legal{} target type and config.install.legal variableBoris Kolpackov1-0/+1
This allows separation of legal files (LICENSE, AUTHORS, etc) from other documentation. For example: ./: ... doc{README} legal{LICENSE} $ b install ... config.install.legal=/usr/share/licenses/hello/
2020-06-29Use buildfile{} instead of build{} for target typeBoris Kolpackov1-1/+1
This feels like an oversight from transitioning to full names, like testscript{}, etc.
2020-06-26Add note to manualBoris Kolpackov1-4/+21
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov1-10/+13
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-08Proofreading fixes to manualBoris Kolpackov1-11/+11