diff options
author | Boris Kolpackov <boris@codesynthesis.com> | 2022-11-09 10:59:36 +0200 |
---|---|---|
committer | Boris Kolpackov <boris@codesynthesis.com> | 2022-11-09 10:59:36 +0200 |
commit | f34dd20fb7578874925dacf21b32338af50e8c12 (patch) | |
tree | 9547f29cc0749c6e9f1f6b9e3e34b1ae8efa525b /libbuild2 | |
parent | 4e547cad02a41d020895eda83088865fecef069a (diff) |
Improve low-level diagnostics in `in` rule (and derived)
Diffstat (limited to 'libbuild2')
-rw-r--r-- | libbuild2/in/rule.cxx | 30 | ||||
-rw-r--r-- | libbuild2/in/target.cxx | 10 |
2 files changed, 38 insertions, 2 deletions
diff --git a/libbuild2/in/rule.cxx b/libbuild2/in/rule.cxx index d07adfc..07c11c6 100644 --- a/libbuild2/in/rule.cxx +++ b/libbuild2/in/rule.cxx @@ -299,7 +299,35 @@ namespace build2 if (verb >= 2) text << program_ << ' ' << ip << " >" << tp; else if (verb) - text << program_ << ' ' << ip; + { + // If we straight print the target, in most cases we will end up with + // something ugly like in{version...h.in} (due to the in{} target + // type search semantics). There is the `...h` part but also the + // `.in` part that is redundant given in{}. So let's tidy this up + // a bit if the extension could have been derived by in_search(). + // + target_key ik (i.key ()); + + if (ik.ext) + { + string& ie (*ik.ext); + const string* te (t.ext ()); + + size_t in (ie.size ()); + size_t tn (te != nullptr ? te->size () : 0); + + if (in == tn + (tn != 0 ? 1 : 0) + 2) // [<te>.]in + { + if (ie.compare (in - 2, 2, "in") == 0) + { + if (tn == 0 || (ie.compare (0, tn, *te) == 0 && ie[tn] == '.')) + ie.clear (); + } + } + } + + text << program_ << ' ' << ik; + } // Read and process the file, one line at a time, while updating depdb. // diff --git a/libbuild2/in/target.cxx b/libbuild2/in/target.cxx index d548453..54130ff 100644 --- a/libbuild2/in/target.cxx +++ b/libbuild2/in/target.cxx @@ -20,6 +20,14 @@ namespace build2 if (!e) { + // Why is the extension, say, .h.in and not .in (with .h being in the + // name)? While this is mostly academic (in this case things will work + // the same either way), conceptually, it is a header template rather + // than some file template. In other words, we are adding the second + // level classification. + // + // See also the low verbosity tidying up code in the rule. + // if (const file* t = xt.is_a<file> ()) { const string& te (t->derive_extension ()); @@ -51,7 +59,7 @@ namespace build2 &target_extension_none, nullptr, /* default_extension */ // Taken care of by search. &in_pattern, - &target_print_1_ext_verb, // Same as file. + &target_print_1_ext_verb, // Same as file (but see rule). &in_search, target_type::flag::none }; |