aboutsummaryrefslogtreecommitdiff
path: root/doc/manual.cli
AgeCommit message (Collapse)AuthorFilesLines
2022-07-26Minor additions to manualBoris Kolpackov1-9/+24
2022-07-18Add few references to manualBoris Kolpackov1-3/+5
2022-07-13In manual adjust link to renamed section in bpkg manualKaren Arutyunov1-2/+1
2022-07-08Update manual with package manager configuration negotiation informationBoris Kolpackov1-3/+89
2022-06-29Rework pkg-config variable naming, use build2.metadata as general indicatorBoris Kolpackov1-5/+5
2022-06-21Add --trace-{match,execute} optionsBoris Kolpackov1-4/+23
These options can be used to understand which dependency chain causes matching or execution of a particular target.
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/.