views:

82

answers:

2

Within several projects, I am using 3rd party code that produce more than a few compiler warnings. I obviously do not want to go through and modify code of actively updated 3rd party projects.

This leaves me with a lot of unnecessary warnings that drown out warnings in MY code.

I have used some compiler flags to suppress specific warnings on a per file basis, but that is much too tedious for open source code with 10-20 .m files.

Is there a way all warnings by Xcode group or file path? Or does somebody have a better suggestion?

(FYI: I am using the LLVM 1.5 compiler)

+2  A: 
David
Using a framework (static lib on the iphone) may be my best hope as you said. I suppose that isn't too much trouble, and should solve the issues. My only problem with that technique, is that if there is a problem, I no longer have source code to look at. This is more a problem of having cake and eating it, or something to that effect…
Corey Floyd
Whether Xcode shows results from the last build or all builds is a setting in the Build Results window. I have mine set to All Builds and my Xcode preferences set to not stop on errors, so that a single build of a fresh project tells me all the warnings and errors it has.
Peter Hosey
The latest results is really the only solution that kinda works. It is just that sometimes real warnings still slip by if I miss them on the first "fresh" build.
Corey Floyd
+1  A: 

This is certainly not the easier solution, but you could go through these third-party libraries and fix their warning-causing bugs and submit patches. Then, the warnings go away, the bugs are fixed, and everybody gets to enjoy both improvements.

(How many warnings you'll be able to squash this way will depend on what they are: Deprecated-API warnings may be unavoidable if the library needs to support an older version of Mac OS X or iOS where the now-deprecated APIs were the only way.)

Peter Hosey
You are right, fixing the warnings is the obvious solution. I have done this in a couple open source projects, but due to time constraints, I can't fix warnings in every open source project I use. It would be ideal to treat the code I do not have time to fix as a "black box". And for some projects, as you mentioned, deprecated calls run amuck.
Corey Floyd