"Walter Bright" <[email protected]> wrote in message news:[email protected]... > 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.
