aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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
2020-07-01Fix bug in *.export.imp_libs logicBoris Kolpackov2-3/+3
2020-07-01Add additional diagnostics for unassigned path (GitHub issue #89)Boris Kolpackov1-6/+10
2020-07-01Add additional diagnostics for disappearing header (GitHub issue #80)Boris Kolpackov1-0/+16
2020-07-01Use <project> substitution in install directoriesBoris Kolpackov1-21/+24
2020-07-01Use legal{} target type for legal documentation (LICENSE, AUTHORS, etc)Boris Kolpackov1-1/+1
2020-07-01Add *.export.imp_libs to get rid of dual *.export.libs semanticsBoris Kolpackov5-36/+42
2020-06-30Add support for <var>-substitutions in config.install.* valuesBoris Kolpackov1-8/+66
For now, the only recognized variable name is <project> which is substituted with the project name. This can be used along these lines: $ b config.install.libexec='exec_root/lib/<project>/' install
2020-06-29Add config.install.share variableBoris Kolpackov2-7/+10
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 Kolpackov5-11/+42
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 Kolpackov2-2/+2
This feels like an oversight from transitioning to full names, like testscript{}, etc.
2020-06-26Drop workarounds for script::redirect struct compile errorsKaren Arutyunov2-58/+4
Thanks to the butl::optional improvement to better deal with lack of copy/move constructors.
2020-06-26Handle #import in MSVC /showIncludes outputBoris Kolpackov2-13/+44
2020-06-26Minor terminology fix in commentsBoris Kolpackov2-4/+3
2020-06-26Fix race in library metadata protocolBoris Kolpackov3-5/+6
Specifically, we need to check whether the prerequisite_member is ad hoc before checking whether it is NULL because ad hoc ones are blanked out (set to NULL) during execute.
2020-06-26Add note to manualBoris Kolpackov1-4/+21
2020-06-25Fix warningBoris Kolpackov1-1/+1
2020-06-25Add more instrumentation for unassigned path raceBoris Kolpackov5-25/+64
2020-06-25Eliminate phase unlock for case where we are not going to waitBoris Kolpackov1-2/+6
2020-06-24Stop forcing modules support in testsBoris Kolpackov1-15/+0
2020-06-24Fix trace and clarify commentsBoris Kolpackov2-9/+15
2020-06-22Disable Clang C++20 modules support unless explicitly forcedBoris Kolpackov1-5/+11
2020-06-22Try to detect and warn about the ccache compiler wrapperBoris Kolpackov1-4/+24
2020-06-22Add version mapping for Apple Clang 11.0.3Boris Kolpackov2-17/+22
2020-06-20Fix assertion failure for unbound 'end' in testscriptKaren Arutyunov3-8/+36
Issue #83.
2020-06-19Adapt mv builtin tests to terminology changeKaren Arutyunov1-1/+1
2020-06-19Raise libcpp version in regex-related check to 10.0Karen Arutyunov1-1/+1
2020-06-19Get rid of unnecessary copyBoris Kolpackov1-1/+1
2020-06-19Fix lexer to fail on invalid UTF-8 sequencesKaren Arutyunov4-0/+96
2020-06-18Complete NetBSD compatibilityBoris Kolpackov6-5/+15
2020-06-18Add NetBSD compatibilitymagenbluten2-4/+4
2020-06-18Add env script pseudo-builtinKaren Arutyunov14-167/+618
Also disable C++ recipe tests when cross-testing.
generated by cgit v1.1 at 2024-11-05 02:11:40 +0000