bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #48643] Irrelevant targets can confuse make on which pattern rule t


From: Steven Simpson
Subject: [bug #48643] Irrelevant targets can confuse make on which pattern rule to select.
Date: Tue, 19 Oct 2021 13:29:43 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]