Dan Jacobson (29 December 2017 03:41)
[snip]
> Therefore please add a new
> '.ALL_WARNINGS_FATAL'
> or something (that we error prone careless
> programmers can use, just like we put
> use warnings FATAL => q(all);
> in all perl files we write today,)
> or make it the default, and instead add a
> '.NO_WARNINGS_FATAL'
> for non-careless programmers.
Interesting idea. It might be better to simply have a command-line
option to make, to make warnings fatal; if you add that to MAKEFLAGS in
your environment, you'd effectively get its effects enabled by default.
cf. gcc's -Werror=... option.
Back to your proposal: these would be built-in target names, so we
should think about what their prerequisites are, which may shape which
side to come from. We'd also need to think about what other warnings
make can produce and whether they're tied to specific targets or not.
.FATAL_WARNINGS: prerequisites...
could sensibly make any warning associated with the given prerequisites
be treated as errors. However, that would fail to target warnings not
associated with any particular target (if there are any). You might
want some wild-card mechanism in the prerequisites, of course; I would
encourage use of % as in pattern rules.
.NONFATAL_WARNINGS: prerequisites...
could let warnings just be warnings, not promoted to errors, for the
designated prerequisites, when they otherwise would be - either due to a
command-line --warnings-are-errors or due to a .FATAL_WARNINGS
elsewhere. As above, this provides no way to turn off an error when the
warning isn't associated with a target; and we may want to support
wildcards.
Having both would raise questions about which takes precedence, when
both mention a prerequisite; would the most specific wild-card win ?
I'm going to guess that's not easy to implement, though.
I normally use make in ways that just generate downstream things, that I
have no problem with over-riding later once I've fixed the warning make
told me about: so I have my doubts about the value of this feature. Of
course, in a large project, that warning may be lost to view amidst the
vast slew of output coming out of make -j32 recursing into many
sub-projects, so a --warnings-are-errors option may be desirable, if
only to exit make promptly, while the warning hasn't fallen off the top
of your scroll-buffer.
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
