diff options
Diffstat (limited to 'libbuild2/config')
| -rw-r--r-- | libbuild2/config/utility.cxx | 28 | ||||
| -rw-r--r-- | libbuild2/config/utility.hxx | 14 |
2 files changed, 36 insertions, 6 deletions
diff --git a/libbuild2/config/utility.cxx b/libbuild2/config/utility.cxx index cf0f73b..b3f94be 100644 --- a/libbuild2/config/utility.cxx +++ b/libbuild2/config/utility.cxx @@ -33,9 +33,31 @@ namespace build2 if (var.overrides != nullptr) { - pair<lookup, size_t> ovr (rs.lookup_override (var, move (org))); - - if (l != ovr.first) // Overriden? + // This is tricky: if we didn't find the original, pretend we have set + // the default value for the purpose of override lookup in order to + // have consistent semantics with the default value case (see notes in + // that implementation for background). + // + // In particular, this makes sure we can first do the lookup without + // the default value and then, if there is no value, call the version + // with the default value and end up with the same result if we called + // the default value version straight away. + // + // Note that we need to detect both when the default value is not + // overridden as well as when the override is based on it (e.g., via + // append; think config.cxx+=-m32). + // + // @@ Maybe a callback that computes the default value on demand is a + // better way? + // + variable_map::value_data v; // NULL value, but must be with version. + if (!l.defined ()) + org = make_pair (lookup (v, var, rs), 1); // As default value case. + + scope::override_info li (rs.lookup_override_info (var, move (org))); + pair<lookup, size_t>& ovr (li.lookup); + + if (l.defined () ? l != ovr.first : !li.original) // Overriden? { // Override is always treated as new. // diff --git a/libbuild2/config/utility.hxx b/libbuild2/config/utility.hxx index bf4728f..cbfe588 100644 --- a/libbuild2/config/utility.hxx +++ b/libbuild2/config/utility.hxx @@ -91,10 +91,16 @@ namespace build2 // // Unlike the rest of the lookup_config() versions, this one leaves the // unspecified value as undefined rather than setting it to a default - // value. This can be useful when we don't have a default value or if we - // want the mentioning of the variable to be omitted from persistent + // value. This can be useful when we don't have a default value or in case + // we want the mentioning of the variable to be omitted from persistent // storage (e.g., a config file) if the default value is used. // + // Note also that we can first do the lookup without the default value and + // then, if there is no value, call the version with the default value and + // end up with the same result if we called the default value version + // straight away. This is useful when computing the default value is + // expensive. + // // @@ Should we pass flags and interpret save_null_omitted to treat null // as undefined? Sounds logical. // @@ -135,7 +141,9 @@ namespace build2 // The second version in addition sets the new_value argument as described // above. Note, however, that if the save_default_commented flag is // specified, then the default value is never considered "new" since for - // such variables absence of a value means it is the default value. + // such variables absence of a value means it is the default value. This + // flag is normally used for dynamically adjusting (e.g., hinted) default + // values. // // If override is true and the variable doesn't come from this root scope // or from the command line (i.e., it is inherited from the amalgamation), |