aboutsummaryrefslogtreecommitdiff
path: root/doc
AgeCommit message (Collapse)AuthorFilesLines
2022-01-16Minor clarifications to wildcard name patterns section in manualBoris Kolpackov1-7/+16
2021-11-09Pass --ascii-tree CLI option when generating embedded usage and man pagesBoris Kolpackov1-1/+3
2021-11-04Document \n escape sequence for sed builtin in testscript manualKaren Arutyunov1-0/+1
2021-10-27Handle "common symbols" in symbol exporting .def generation ruleBoris Kolpackov1-2/+2
2021-10-26Minor documentation tweakBoris Kolpackov1-6/+6
2021-10-20Change to version 0.15.0-a.0.zBoris Kolpackov1-1/+1
2021-10-16Release version 0.14.0v0.14.0Boris Kolpackov1-1/+1
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-13Add --cwd|-t option to env pseudo-builtinKaren Arutyunov1-3/+8
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-11Add export script pseudo-builtinKaren Arutyunov1-6/+40
2020-12-08Add support for config.test.runnerKaren Arutyunov2-2/+42
2020-12-07Update submodulesBoris Kolpackov1-0/+0
2020-11-25Allow multiple -e options for sed builtinKaren Arutyunov1-7/+9
2020-11-23Document include and source directivesBoris Kolpackov1-1/+32
2020-11-06Add support for test timeoutsKaren Arutyunov3-3/+72
2020-10-18Make some documentation fixesFrancois Kritzinger2-77/+78
2020-10-15Add ability to specify fallback value for NULL substitutions with in.nullBoris Kolpackov1-0/+13
2020-10-05Update submodulesBoris Kolpackov1-0/+0
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-21Change to version 0.14.0-a.0.zBoris Kolpackov1-1/+1
2020-07-18Release version 0.13.0v0.13.0Boris Kolpackov1-1/+1
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.
generated by cgit v1.1 at 2024-12-22 08:37:15 +0000