From 317e2cb68753c7b89783a3c829ba53889a370f8c Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Thu, 20 Jul 2023 10:18:54 +0200 Subject: Don't treat unmatched prerequisites as implicitly ad hoc It was surprising and inconvenient that they didn't end up in $<. Plus, such prerequisites can always be marked as ad hoc explicitly. --- libbuild2/adhoc-rule-buildscript.cxx | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) (limited to 'libbuild2/adhoc-rule-buildscript.cxx') diff --git a/libbuild2/adhoc-rule-buildscript.cxx b/libbuild2/adhoc-rule-buildscript.cxx index fd0411f..3c42e66 100644 --- a/libbuild2/adhoc-rule-buildscript.cxx +++ b/libbuild2/adhoc-rule-buildscript.cxx @@ -533,7 +533,7 @@ namespace build2 l6 ([&]{trace << "unmatch " << *pt.target << ": " << mr.first;}); // If we managed to unmatch, blank it out so that it's not executed, - // etc. Otherwise, convert it to ad hoc (we also automatically avoid + // etc. Otherwise, leave it as is (but we still automatically avoid // hashing it, updating it during match in exec_depdb_dyndep(), and // making us out of date in execute_update_prerequisites()). // @@ -557,10 +557,16 @@ namespace build2 // treat it as ordinary ad hoc since it has the target pointer in // data). // - pt.include &= ~prerequisite_target::include_adhoc; + // But that makes it impossible to distinguish ad hoc unmatch from + // ordinary unmatch prerequisites later when setting $<. Another + // flag to the rescue. + // + if ((pt.include & prerequisite_target::include_adhoc) != 0) + { + pt.include &= ~prerequisite_target::include_adhoc; + pt.include |= include_unmatch_adhoc; + } } - else - pt.include |= prerequisite_target::include_adhoc; } } } -- cgit v1.1