diff options
| author | Boris Kolpackov <boris@codesynthesis.com> | 2021-09-20 15:59:39 +0200 |
|---|---|---|
| committer | Boris Kolpackov <boris@codesynthesis.com> | 2021-09-20 15:59:39 +0200 |
| commit | b7cb7f5510de019527f2a7b9e3f81dbb9813b5d9 (patch) | |
| tree | b204239436d477224a8664c82d8cf08a9629a504 /libbuild2/context.hxx | |
| parent | ab978916ef5d3a8f876953697c6eb9cdeedbc998 (diff) | |
Add support for disabling clean through target-prerequisite relationship
Our current semantics is to clean any prerequisites that are in the same
project (root scope) as the target and it may seem more natural to rather only
clean prerequisites that are in the same base scope. While it's often true for
simple projects, in more complex cases it's not unusual to have common
intermediate build results (object files, utility libraries, etc) reside in
the parent and/or sibling directories. With such arrangements, cleaning only
in base (even from the project root) may leave such intermediate build results
laying around (since there is no reason to list them as prerequisites of any
directory aliases). So we clean in the root scope by default but now any
target-prerequisite relationship can be marked not to trigger a clean with the
clean=false prerequisite-specific value.
Diffstat (limited to 'libbuild2/context.hxx')
| -rw-r--r-- | libbuild2/context.hxx | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/libbuild2/context.hxx b/libbuild2/context.hxx index c93c1c9..7ac4af4 100644 --- a/libbuild2/context.hxx +++ b/libbuild2/context.hxx @@ -411,6 +411,9 @@ namespace build2 // const variable* var_extension; + // Note that this variable can also be specified as prerequisite-specific + // (see the `include` variable for details). + // // [bool] target visibility // const variable* var_clean; @@ -450,6 +453,15 @@ namespace build2 // A rule with the "pass-through" semantics should treat the adhoc value // the same as true. // + // Sometimes it may be desirable to apply exclusions only to specific + // operations. The initial idea was to extend this value to allow + // specifying the operation (e.g., clean@false). However, later we + // realized that we could reuse the "operation variables" (clean, install, + // test) with a more natural-looking result. Note that currently we only + // recognize the built-in clean variable (for other variables we will need + // some kind of registration in an operation-to-variable map, probably in + // root scope). + // // To query this value in rule implementations use the include() helpers // from <libbuild2/prerequisites.hxx>. // |