Re: [bug #56732] VPATH doesn't work with pattern rules
On 8/10/19 8:16 AM, anonymous wrote: > Follow-up Comment #3, bug #56732 (project make): > > OK, this is a special case I didn't remembered. The wording in the manual > doesn't touch implicit rules, so one can assume it should work for them too. > > I don't know how much application of rules differs between normal and implicit > ones, so I can't help beyond this point. > The Make manual also shows that the implementation of library search rules as discussed here is itself a pattern rule, so it wouldn't surprise me if a pattern rule within a pattern rule is unsupported. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Treat "Circular dependency...dropped" as a hard error instead?
I have a GNU make-based build system wherein I would like for any/all GNU make-detected circular dependencies to be treated as a hard error, i.e., fail [immediately], rather than a "dropped and we go on without it..." situation. Is there a way to do this already? I do NOT suggest to change default behaviour, as there are likely an uncountably-infinite number projects that accept/depend on current behaviour, but perhaps a command line option or a ".CIRCULARERROR:" rule or some way to allow this to be turned on by those who need it? In my case, a circular dependency is a coding error in the Makefile's by the build-engineer, and I don't want it to slide by... Thanks, jzb
Re: Treat "Circular dependency...dropped" as a hard error instead?
On 5/11/24 06:11, Dmitry Goncharov wrote: On Wed, May 8, 2024 at 2:04 PM JZB wrote: ... perhaps a command line option or a ".CIRCULARERROR:" rule or some way to allow this to be turned on by those who need it? There is currently no mechanism (option or otherwise) to fail on a circular dependency. On top of that, there are situations when make drops a circular dependency silently. See https://savannah.gnu.org/bugs/?60736. regards, Dmitry Thanks Dmitry, that provides some background. To be honest, I don't quite understand Paul's logic, in that his approach to a global .EXTRA_PREREQS silence should be the exception, not the default. I can screw-up a global .EXTRA_PREREQS just as readily as I can a target-specific one, maybe even more so. However, if there existed a rule, such as what I proposed, a ".CIRCULARERROR:", and it should be global, never target specific (should be easier to implement), because I either care about circular dependencies being errors or I don't (and that is project-wide, not per-target), and have that take precedence over the silent/not-silent-warning issue, it would actually be a compromise between the two sides on > https://savannah.gnu.org/bugs/?60736. In other words, current behaviour stays as Paul has it, but if the user wants circular dependencies to be errors, then Dmitry's algorithm has prioriry, and yes, that should include .EXTRA_PREREQS as well. --jzb
Re: Treat "Circular dependency...dropped" as a hard error instead?
On 5/13/24 21:05, Dmitry Goncharov wrote: On Wed, May 8, 2024 at 2:04 PM JZB wrote: I have a GNU make-based build system wherein I would like for any/all GNU make-detected circular dependencies to be treated as a hard error, i.e., fail [immediately], rather than a "dropped and we go on without it..." situation. Is there a way to do this already? I think, that's a good idea. i added two patches which implement this ability. You'll need to wait for make with the patches to be released or apply the patches yourself. See https://savannah.gnu.org/bugs/index.php?65739. regards, Dmitry Thanks, Dmitry...that's awesome! I'm sure the user community will appreciate it. I know I do. --jzb
Re: [bug #60736] Introduce "Circular <- dependency dropped." for .EXTRA_PREREQS deps.
On 5/19/24 18:25, Paul D. Smith wrote:
Follow-up Comment #6, bug #60736 (group make):
I think that using a warn option is better than forcing this to always warn.
But I still think that the warning makes global usage useless, and since
there's no way to control warnings on a per-target basis (today) it means the
warning is hard to use.
It seems to me that we have two different behaviors: for global .EXTRA_PREREQS
I just can't imagine anyone ever wanting to enable this warning. Can someone
show an example of a situation where it would be useful for global
.EXTRA_PREREQS?
But for target-specific .EXTRA_PREREQS I can see how it could be useful.
So maybe what we want to do instead of (or in addition to) creating the
warning is to say that the entire behavior of omitting extra prereqs as a
prerequisite to itself only applies to global .EXTRA_PREREQS; that is in the
manual instead of:
Note @code{make} is smart enough not to add a prerequisite listed in
@code{.EXTRA_PREREQS} as a prerequisite to itself.
we make it explicit (and in the code) that this only applies to global
.EXTRA_PREREQS; something like:
Note @code{make} is smart enough not to add a prerequisite listed in a
global setting of @code{.EXTRA_PREREQS} as a prerequisite to itself.
Then we can keep all the default behaviors, including warning about circular
dependencies using the already existing warning option for this that you
proposed in the other bug, because by definition those warnings won't apply to
global .EXTRA_PREREQS due to the special case above, but they will still apply
to target-specific .EXTRA_PREREQS.
Thoughts?
As long as comment #6 is only referring to the special case of "target
never added as a prerequisite to itself via global .EXTRA_PREREQS," then
there is no need for the warning, because by definition there is no
circular dependency caused by global .EXTRA_PREREQS. So in essence, the
situation becomes "make is not going to warn about something it didn't
do..." The slight clarification in the manual is thus sufficient.
But it should still warn about other circular dependencies caused by
users setting global .EXTRA_PREREQS, which is current behaviour already:
.EXTRA_PREREQS = a
a: b
b: c
c: d
d:
@echo making $@
$ make
make: Circular d <- a dependency dropped.
making d
make: Circular c <- a dependency dropped.
make: Circular b <- a dependency dropped.
So the corner-case of no warning for a <- a is fine, but this is where
the choice of :warning or :error for the rest is still useful, though
the circularity is caused by global .EXTRA_PREREQS. It is not clear
from the last sentence of comment #6 what the proposal is in terms what
happens in such case.
There is one other small improvement I'd like to request in terms of
reporting the circular dependencies, and this is almost off topic, but
maybe it can be squeezed in to this bug, or I can open a new request,
whatever is better:
In the make snippet above the output shows
make: Circular d <- a dependency dropped.
but what would be immensely more useful are the missing intermediate
targets, i.e.:
make: Circular d <- c <- b <-a dependency dropped.
Tracking down circular dependencies at the moment is usually accompanied
by digging through tons of output from the -d flag, which is
time-consuming when all I'd really need is the [longer] cycle path itself.
