This started on irc, then moved to -users, but seems more a -dev topic.
Trying a more detailed summary here.
There's a whole list of scons warnings. Implementation is a simple
scons Warning class, which is a subclass of UserError, which is a
subclass of Python's Exception class. The warnings are either a
subclass of Warning, or a subclass of WarningOnByDefault, which is in
turn a subclass of Warning. There are a few more things that play in
this game, like DeprecatedWarning, FurtureDeprecatedWarning,
MandatoryDeprecatedWarning. This technique, for better or for worse,
provides identification using isinstance and issubclass.
One particular warning has been irritating me, namely that a missing
sconscript is only a warning, when it would help me if it were an error.
There is an existing variable SCons.Warnings._warningAsException which
causes any warning to raise an exception (the check is in the warn
function). The result is not ideal (but more on that later). There is
no "API" to modify this flag, but it's Python, I can reach in and
twiddle it myself if needs be.
There are a bunch of different ways to address making controlling the
behavior a little more convenient.
- addressing only the missing scripts, the call to SConscript could grow
a must-exist flag. Since this can't immediately default to error
(suggestion was a deprecation-warning first) there should be something
to toggle the behavior too, without having to modify the individual
SConscript calls.
- a simple API could turn on warnings-as-errors - just fiddling the flag
mentioned above.
- a more complex API could turn on/off warnings-as-errors for individual
warnings (and there's no reason not to include an "all" option at the
same time)
After hacking a little bit I have an implementation of the third choice
(--werror=[no-]WARNINGSPEC), which along the way also could be used
(after simplification) for the second, but perhaps the first choice is
actually the more natural one? The behavior of SConscripts "feels" like
a unique case from the others.
In all the options (there may well be more) there are
backwards-compatibility questions, and testing questions (tests expect
the current behavior and would likely break).
The behavior of _warningAsException isn't really pretty. The warn
function has already made a class instance, so no more information is
readily available to pass to it when it does the raise, leading to my
hacked build ending like this:
scons: *** ("Ignoring missing SConscript 'tizen/SConscript'",)
File "/home/mats/work/tmp/SConstruct", line 36, in <module>
That's the desired outcome, but the message is odd: the warning classes
aren't really set up to be raised as errors as seen by the style of the
message which is formatted oddly, the exception class is not displayed,
and it includes the word Ignoring (the message is passed in from the
SConscript module which at that point expects it's going to be a warning
only), present even though in this case it's clearly not ignoring. That
needs some work. Tests depend on this message being a warning, by the
way looking for the text between the quotes exactly.
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
