> On Tue, May 31, 2016 at 07:39:15PM +0100, Colin Clark wrote: >>> There may be people trying to use Geeqie who struggle just to download a >>> tar and do a make. For them, compiler warnings are an unnecessary worry, >>> because they do not understand that the warnings are in fact irrelevant >>> to them. >> I don't think that people who struggle over that output will ever >> compile geeqie themself. They use the version, the distribution is >> giving him. >> >I understand your point of view, but I am not in complete agreement. > >I can do a few things with software, but I have no patience when I am >trying to get other people's software to run. If I download something >from the interweb, do a configure/make and get a screen-full of >messages, I will not spend any time trying to understand it. I will find >another app and try that. > >I would rather leave endless messages that may or may not be meaningful >to the profis. > >I much prefer programs that, if they create a run-able binary, show no >message other than "It works, try it". I would prefer Geeqie to be that >way, but I am also happy for it to stay as it is.
Those are what those warnings are meant for, for the developer to migrate from functions that are going to be deprecated within the future. Sometimes those warnings may be displayed only on a person's unique platform or the person's build environment which is different from the developer's build environment. If you think you're only seeing the warnings (due to building on sparc, bsd, ...), then maybe forwarding the warnings to the mailing list or developers would help bring them to light. (Correct me if I'm wrong here, but just realized this perspective just now.) I think the warnings I see while building, are clearly indicated by "Warning: " prefix. When compiling breaks, the warnings are usually a strong indicator just prior to a failed compiled statement. Usually you'll see 20-40 warnings when scanning the compiler stdout or compiler text logs, immediately prior to a statement compiling failure. Without these sometimes numerous warnings prior to breaking, the person compiling is left for looking for one compiler error amongst compiler stdout. (This usually occurs within when using the option "-j" with large values, etc. Most times, users can just ignore the warnings unless the compiler fails. Sort of like buying a used car with it's documented history showing. Hiding the warnings, would be likely buying a used car without knowing it's history. Also, warnings are sometimes indicative of unmaintained code, likely to break within the future. Most users never see the compiler messages, as most just use the software. If I'm not mistaken, those compiling can further customize the compiler messages by modifying their make.conf file. Most just leave them at defaults, while developers tend to significantly increase verbosity... especially when things break. -- Roger http://rogerx.freeshell.org/ ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
