[Top][All Lists]

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

[bug #63686] implement a flag to promote make warnings to fatal errors

From: David Boyce
Subject: [bug #63686] implement a flag to promote make warnings to fatal errors
Date: Mon, 27 Feb 2023 10:04:01 -0500 (EST)

Follow-up Comment #10, bug #63686 (project make):

Again, I'm generally ok with your implementation. No big objections, but in an
attempt to carry these discussions to closure:

> MAKEFLAGS are by definition passed to recursive makes ...

My $dayjob builds, among other things, a Linux kernel module. Kernel modules
must be built within the context of the Linux kernel build model. We have a
wrapper makefile which populates the appropriate corner of a kernel tree with
our files and then recursively invokes the kernel build system with flags
saying "build this module for this kernel". The upshot is that if we put
"MAKEFLAGS += --warn=error" in our setup makefile it would be inherited into
the Linux kernel system which may or may not handle it well. Of course this is
just one example of the general class of cases where recursing into a
third-party build model is necessary.

It could be worked around ($(MAKE) MAKEFLAGS="$(patsubst ...)" ...) but it's
worth considering which model is more flexible in a cooperative arrangement.

> A special target can't be in effect until it appears in the makefile, unlike
a command line option which is always in effect.

Is it possible to imagine a scenario where a particular warning must be
tolerated while we still want "error" behavior in general? Demoing with the
special target syntax:

.WARNINGS: ignore
<problematic code>
.WARNINGS: error
<everything else>

> There is an argument to be made that requiring every individual makefile to
include its own .WARNINGS: special target (or whatever we decide to call it)
will be unpleasant ...

This seems like the flip side of what I mentioned above. AFAICT the difference
between --warn/MAKEFLAGS and .WARNINGS:/-E matters only in recursive
invocation, and in that case not having the behavior transmitted automatically
could be seen as a feature as well as a bug.


Reply to this item at:


Message sent via Savannah

reply via email to

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