How DMD's -w *Prevents* Me From Seeing My Warnings

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:hl4krg$2uku$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> Ok, that is a big improvement (thanks!!!), but this still remains:
>>
>> 1. I compile my program, with warnings as I always do (because I want to 
>> be told about them, and as early as possible).
>> 2. I fix all my errors, but I get a warning in an external library.
>> 3. Now I have to go modify my build script and recompile just to get the 
>> output files that DMD arbitrarily refused to give me before (and then go 
>> edit my built script again to turn them back on). Which is not 
>> impossible, but it's all for...what benefit exactly? I mean, even if 
>> there were a legitimate reason for forcing any warnings to suppress 
>> output files (and I very much dispute that there is), the fact I can get 
>> the same damn output files anyway by shutting the warnings off and 
>> recompiling renders the whole "feature" pointless. You may as well just 
>> write the output files anyway and save people the bother of working 
>> around it.
>
> Here's how I set up a makefile to build with different options:
>
....
>
> So, for your case, I'd "make warnings", fix all the warnings that I intend 
> to, then just do "make" for the executable build.
>

I already have "make debug" (for normal development, and it's ***with all 
warnings*** because, after all, its for *my normal development* and 
obviously I want to see any problems as soon as possible) and "make release" 
(for distribution)...so far...

Since that one null-checking feature only happens with optimizations 
enabled, I have to add the optimization flag to my debug build, which means 
that I'm also going to have to make a new "make debuggable_debug" for when 
I, or anyone else, wants to use a debugger on my apps.

And now I'm *also* expected to add on top of all that "make debug_nowarn" 
for whenever a warning shows up, and, naturally, a "make 
debuggable_debug_nowarn" for when I, or someone, wants to use a debugger 
during a time when an outside library has a warning.

And of course, I now have to do a recompile any time I need to switch 
between any of the ever-growing plethora of so-called "debug" builds. And 
keep in mind too, like *many* people, I don't build form the command-line, I 
set up an tool in my editor, and believe me, that tool list is getting 
fucking looong. All these extra build configurations are just simply a 
completely unnecessary mess.

And yet, were it not for DMD, there would be no reason I couldn't just keep 
it a nice simple "debug" vs "release" like I can with every other damn 
compiler on the planet.

> As for why warnings don't just slide through without creating any errors, 
> I'll give my usual rant on them:
>
> If they go ahead and produce the output files anyway, you never see them! 
> They scroll up and off your window, you don't notice them. Your automated 
> build system never notices them, and happily reports that everything went 
> swimmingly.
>

If someone has that problem, they can just stick with the default "warnings 
as errors". In my setup, I don't have that problem, so why should *I* who 
*does* see them without them scrolling off the screen, not be able to 
choose? If you add in the "warnings as warnings" option, then by *actively* 
turning that on, they're asserting that they either do see warnings in their 
setup like I do or it's their own damn problem.

Plus, you're really worried about scrolling, you can also have an "Exited 
with X error(s), and Y warning(s)" summany at the end like MSVC has had for 
decades.

> Your difficulty with the 3rd party library warnings is a classic example 
> of why I spent a lot of energy resisting having warnings in the language 
> in the first place.

An admirable idea, but I think D's proven that strategy just doesn't work in 
practice.