> 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 


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

Reply via email to