"BCS" <[email protected]> wrote in message news:[email protected]... > Hello Nick, > >> "BCS" <[email protected]> wrote in message >> news:[email protected]... >>> I'd also not mind see an orthogonal way to suppress warnings in >>> libraries; maybe only do warnings in packages not reached via include >>> paths give via -I >>> >> I could live with or without that. If it were to be done, another idea >> is something like: >> >> "-w+package_name" -> Turn on warnings for package "package_name" and >> all sub-packages >> "-w-package_name" -> Turn off warnings for package "package_name" and >> all sub-packages >> "-ww+package_name" -> Turn on (but ignore) warnings for package >> "package_name" and all sub-packages >> >> That would give more control, but something closer to your way might >> be cleaner or more convenient. > > I can't think of any reason to turn on warnings starting at any root other > than the files listed on the command line
Good point. So scratch the "-w+package_name" and "-ww+package_name" parts. > and I can't think of any good reason to turn off warnings at any point > that isn't a ownership or library boundary. Neither can I, but how else is the compiler going to know where those boundaries are if not via a package/module name? The more I think about it, the more convinced I am that going by "included via -I or not?" is a bad idea, because even I've included third-party code without -I and included my own code with -I, and had reason (or at least "good enough" reason anyway) to do so.
