Follow-up Comment #11, bug #48643 (project make): I saw a couple of tests in targets/NOTINTERMEDIATE failing, 2 and 10. Preserving an already set notintermediate flag (in the same way that intermediate is preserved) allows the tests to pass. This (src/implicit.c#919):
f->notintermediate = imf->notintermediate; f->intermediate = !(pat->is_explicit || f->notintermediate); ...becomes: f->notintermediate = f->notintermediate || imf->notintermediate; f->intermediate = f->intermediate || !(pat->is_explicit || f->notintermediate); It's almost the same issue as before. Without the f->is_target test, the deplist entry is set at around line 777, the branch at 892 fails, so the lines above are avoided. With it, the entry is set at 821, and the branch at 892 passes. [comment #6 comment #6:] > I'm seeing some failures after applying this patch. Now [make check] reports no failures, although features/guile and vms/library are N/A, and options/dash-I warns of non-numeric arguments. Were you seeing any others? > That is, pattern rule trees are searched "width first", not "depth first". (By "width first" do you mean "breadth-first"? I think the point might be moot, though, since depth-vs-breadth affects the order of solutions, but we're talking about whether foo:bar is a solution at all when looking for bar.) > In the example we have: > > default: a.foo > %.foo: %.correct ; @echo $@ from $< > %.foo: %.mislead ; @echo $@ from $< > [snip] > > misleading_target: a.mislead > > It's true that it's a prerequisite of some completely different target, and we're not even trying to build that target, but that doesn't matter. The rule 5.3 in the above page says that it matches if all the prerequisites "exists or *ought to exist*". As can be seen in the rule statement, the definition of "ought to exist" is simply, "is mentioned in the makefile as a target or as an explicit prerquisite". You're right - it's there in black and white. But it seems to me an odd definition of "ought to exist" for the purpose. (So, yes, I seem to have a similar position to Boris's.) If you've tentatively identified that a.foo could be built from a.mislead, you want to be looking next for a rule that *targets* a.mislead, not merely one that mentions it. Otherwise, you're not forming a chain A:B, B:C, C:D, etc. Furthermore, having failed the (f = lookup_file) test, execution shortly goes on to look for another pattern rule (by the recursive call to pattern_search), and it will be matching against the target side of the rule, not the prerequisite side (right?). I'm not certain of this, so I'd be interested in seeing other cases where the broader definition is required. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?48643> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/