Follow-up Comment #5, bug #18139 (project make):
Boris, I don't see why %.o being intermediate makes a difference. Make can
and does chain implicit rules. I re-read the section on chaining and I don't
see anything that would contradict the basic premise of chaining, which is
that the length of
Follow-up Comment #2, bug #18124 (project make):
FYI, there's some conversation on this bug over in the Red Hat Bugzilla
database. I don't understand the bug and the patch doesn't enlighten me, so
I'm asking for some more detail.
___
Repl
Follow-up Comment #9, bug #15919 (project make):
I have a fix, which works with the two Makefiles that are attached to this
bug, plus my stripped down makefile, plus the real life makefile that it was
stripped from.
It also passes the "make check" stage.
It also fixes another old bug.
Paul, ho
Follow-up Comment #6, bug #18139 (project make):
When GNU make is trying to match a target to an implicit rule it does it in
two passes (implicit.c:432): first without intermediate prerequisites and
then with them. If %.o results in an interemdiate then, on the first pass,
the first rule will be
Follow-up Comment #7, bug #18139 (project make):
I think the confusion comes from that the top-goal in the makefile is not
what it actually should be, that is just:
all: $(LIBS)
Normally you would expect this to work but by the implications that Boris
mentionned it doesn't.
Tnen, there are
Follow-up Comment #8, bug #18139 (project make):
Hm. Boris, is that the way it's always worked or is it something we changed
recently? According to the docs as far as I can tell there's no such
distinction between rules that require intermediates and those that don't.
In fact, it seems pretty
Follow-up Comment #10, bug #15919 (project make):
Hi Icarus. The easiest way to get a patch into GNU make is to attach it to
the bug report and/or create a separate patch item (the first is preferred).
We'll review it and apply it as-is or else discuss it with you if necessary.
Also, if the pa
