aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/context.hxx
diff options
context:
space:
mode:
Diffstat (limited to 'libbuild2/context.hxx')
-rw-r--r--libbuild2/context.hxx13
1 files changed, 6 insertions, 7 deletions
diff --git a/libbuild2/context.hxx b/libbuild2/context.hxx
index 9cb4fb4..b426ea0 100644
--- a/libbuild2/context.hxx
+++ b/libbuild2/context.hxx
@@ -253,7 +253,7 @@ namespace build2
// change already existing nodes or invalidate any references to such (the
// idea here is that one should be able to load additional buildfiles as
// long as they don't interfere with the existing build state). The
- // "islands" are identified by the load_generation number (0 for the
+ // "islands" are identified by the load_generation number (1 for the
// initial/serial load). It is incremented in case of a phase switch and
// can be stored in various "nodes" to verify modifications are only done
// "within the islands". Another example of invalidation would be
@@ -263,6 +263,10 @@ namespace build2
// for example, we may have queried a variable which in the new hierarchy
// would "see" a new value from the newly inserted scope.
//
+ // The special load_generation value 0 indicates initialization before
+ // anything has been loaded. Currently, it is changed to 1 at the end
+ // of the context constructor.
+ //
run_phase phase = run_phase::load;
size_t load_generation = 0;
@@ -309,11 +313,6 @@ namespace build2
const operation_info* current_inner_oif;
const operation_info* current_outer_oif;
- // Current operation-specific variables.
- //
- const variable* current_inner_ovar;
- const variable* current_outer_ovar;
-
action
current_action () const
{
@@ -549,7 +548,7 @@ namespace build2
// 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-specific variables"
- // (update, clean, install, test; see context::current_ovar) with a more
+ // (update, clean, install, test; see project_operation_info) with a more
// natural-looking and composable result. Plus, this allows for
// operation-specific "modifiers", for example, "unmatch" and "update
// during match" logic for update (see var_update for details) or