aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-06Double default task queue sizeBoris Kolpackov1-1/+1
Testing shows quite a lot of "full" conditions on low core count (e.g., 2) CPUs (such as Intel U-series).
2020-08-04Fix 'target.path() called out of scope' testscript errorKaren Arutyunov1-0/+7
2020-08-03Fix buildscript diagnostics so diff output is always in unified formatKaren Arutyunov3-12/+70
Also make sure diff refers program stdout as 'stdout' rather than '-' in the test rule diagnostics.
2020-07-23Escape quotes in .pc file values besides spaces and backslashesKaren Arutyunov1-1/+1
2020-07-21Change to version 0.14.0-a.0.zBoris Kolpackov3-4/+4
2020-07-18Release version 0.13.0v0.13.0Boris Kolpackov3-6/+6
2020-07-18Work around Clang bug #45021Boris Kolpackov1-0/+10
2020-07-18Minor fix in manualBoris Kolpackov1-2/+2
2020-07-18Add $regex.find_match() and $regex.find_search() functionsKaren Arutyunov3-0/+184
2020-07-17Update submodulesBoris Kolpackov1-0/+0
2020-07-17Fix race in path/mtime assignment and file_rule::match()Boris Kolpackov7-30/+43
2020-07-17Add optimized derive_path_with_extension(), use in file_ruleBoris Kolpackov4-14/+42
2020-07-17Minor documentation updatesBoris Kolpackov2-4/+20
2020-07-17Use -fexternc-nounwind by default for Clang targeting MSVCBoris Kolpackov1-5/+27
This option implements the 'c' part in /EHsc and is not a mere optimization; see Clang bug #45021 for details.
2020-07-16Tweak NEWS file some moreBoris Kolpackov1-5/+6
2020-07-16Minor tweaks to NEWS fileBoris Kolpackov1-12/+14
2020-07-16Save original compiler path/mode in {c,cxx}.config.path/modeBoris Kolpackov10-13/+26
It turns out that when propagating {c,cxx}.config in tests we don't want to propagate any options (such as *.std) that have been folded into our project's mode.
2020-07-16Documentation updatesBoris Kolpackov2-70/+98
2020-07-14Fix Clang warningBoris Kolpackov2-0/+4
2020-07-14Update NEWS fileBoris Kolpackov1-0/+269
2020-07-14Add another note on wildcards inside eval contextBoris Kolpackov1-3/+15
2020-07-14Recognize `build2` as special module name in addition to `build`Boris Kolpackov1-2/+2
This is for consistency with version constraints in manifest.
2020-07-13Fix version check in using directiveBoris Kolpackov1-8/+9
2020-07-13Document value subscriptsBoris Kolpackov1-3/+15
2020-07-13Reserve backtick (`) and bit-or (|) in eval context for future useBoris Kolpackov6-5/+25
Specifically, they are reserved for future support of arithmetic evaluation contexts and evaluation pipelines, respectively.
2020-07-13Add ability to extend rule interface in source-compatible mannerBoris Kolpackov12-23/+68
2020-07-13Fold translated *.std options into compiler mode optionsBoris Kolpackov8-55/+35
This way they are accessible in ad hoc recipes.
2020-07-12Rename rule-adhoc-* to adhoc-rule-*Boris Kolpackov5-15/+15
2020-07-12Cache subprojects variable value in scope::root_extraBoris Kolpackov8-57/+61
2020-07-10Fix bugBoris Kolpackov1-1/+1
2020-07-10Relax prerequisite filtering semantics of aliases for clean operationBoris Kolpackov2-4/+7
This is analogous to what has been done to test and install a couple of commits before.
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 Kolpackov2-11/+47
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-10Tweak rule namesBoris Kolpackov3-3/+4
2020-07-09Make sure update-for-{test,install} works for files out of any projectBoris Kolpackov2-2/+18
2020-07-09Relax prerequisite filtering semantics of aliases in test and install rulesBoris Kolpackov3-5/+11
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 Kolpackov8-241/+438
2020-07-09Get rid of no longer needed friendBoris Kolpackov1-4/+0
2020-07-08Fix bug in switch_scope()Boris Kolpackov1-1/+1
2020-07-07Make sure paths used to insert target are canonicalizedBoris Kolpackov1-3/+9
2020-07-07Skip sources of executables in cc::install_ruleBoris Kolpackov2-9/+28
Failed that, they may pull headers via an ad hoc group.
2020-07-06Adjust variable block applicability in dependency chainsBoris Kolpackov5-112/+228
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-03Cutoff amalgamation and subproject for simple projectsBoris Kolpackov2-43/+37
2020-07-02Hopefully fix flaky permission denied in `in` module on WindowsBoris Kolpackov1-1/+9
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-07-02Optimize variable extraction in bootstrap_src()Boris Kolpackov3-79/+69
2020-07-02Cache project name in root_extraBoris Kolpackov5-19/+55
2020-07-01Add support for private installationsBoris Kolpackov1-42/+109
generated by cgit v1.1 at 2024-11-01 09:26:49 +0000