aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/context.hxx
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2021-09-20 15:59:39 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2021-09-20 15:59:39 +0200
commitb7cb7f5510de019527f2a7b9e3f81dbb9813b5d9 (patch)
treeb204239436d477224a8664c82d8cf08a9629a504 /libbuild2/context.hxx
parentab978916ef5d3a8f876953697c6eb9cdeedbc998 (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.hxx12
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>.
//