[asterisk-scf-dev] building asterisk-scf part2

[Brent Eagles]

On Oct 22, 2011, at 2:31 PM, Paul Belanger wrote: 

> Is there a simple way to allow the warnings? I know the proper fix is to actually fix them, but I have some free time ATM and wanted to see if I could get a build to work. 

I've been thinking about this. 

This warning is in the code generated by slice2cpp (which is why it's not just a simple fix). I wonder if treating warnings as errors for generated code is worthwhile. 

Many warnings indicate potential problems resulting from people maintaining the code instead of problems with the code itself. But since the code is generated by a program, who cares if it's maintainable? Does is matter if generated code has unused variables? Or unused parameters? 

I propose that we either disable warnings for the compiling of generated .cpp files, or at least disable the warnings that indicate code maintenance problems. 

Thoughts? 

When I saw the e-mail(s) at the beginning of this thread and re-read the bug report, the same notion started to creep in. Is it reasonable to adopt a position that would require us to "fix" the slice2cpp translator each time a new version of slice2cpp is released t hat produces code that triggered warnings or, better still, when a new version of a C++ compiler comes out that generates a new warning? Granted the translators and compiler are not likely to change that often, but it could become a pain. Disabling -Werror on slice2cpp generated code seems to be a reasonable solution and should work as long as the code that is producing the warnings is not defined in a header file and inlined (and not actually broken, of course). 


Cheers, 


Brent 



-- 
Brent Eagles 
Digium, Inc | Software Developer 
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA 
Check us out at: www.digium.com & www.asterisk.org 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-scf-dev/attachments/20111024/a0b7e3bc/attachment.htm>