Oops, I forgot to add a proper NEWS entry!
Oh well, no big deal, since it was the last thing to add
anyway.
Regards,
Stefano
-*-*-*-
Update NEWS about the warnings-over-strictness precedence.
* NEWS: Automake explicit warning levels always take precedence
over the implicit warning levels implied by Automake strictness.
---
ChangeLog | 6 ++++++
NEWS | 10 ++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index e1b23b2..c952446 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
2010-12-20 Stefano Lattarini <stefano.lattar...@gmail.com>
+ Update NEWS about the warnings-over-strictness precedence.
+ * NEWS: Automake explicit warning levels always take precedence
+ over the implicit warning levels implied by Automake strictness.
+
+2010-12-20 Stefano Lattarini <stefano.lattar...@gmail.com>
+
Warnings win over strictness in AUTOMAKE_OPTIONS.
This change ensures that, for what concerns the options specified
in AUTOMAKE_OPTIONS, explicitly-defined warnings always take
diff --git a/NEWS b/NEWS
index 5e24313..d3bbef4 100644
--- a/NEWS
+++ b/NEWS
@@ -91,6 +91,16 @@ Bugs fixed in 1.11a:
- Rules generated by Automake now try harder to not change any files when
`make -n' is invoked. Fixes include compilation of Emacs Lisp, Vala, or
Yacc source files and the rule to update config.h.
+
+ - Now explicit enabling and/or disabling of Automake warning categories
+ through the `-W...' options always takes precedence over the implicit
+ warning level implied by an Automake strictness (foreign, gnu, gnits),
+ regardless of the order in which such strictness and warning flags
+ appears. For example, a setting like:
+ AUTOMAKE_OPTIONS = -Wall --foreign
+ will cause the warnings in category `portability' to be enabled, even
+ if those warnings are by default disabled in `foreign' strictness.
New in 1.11:
--
1.7.2.3
