Warnings in Juce's Objective C under XCode 4?


I finally made the upgrade to OS/X 10.8 (from 10.6) and XCode 4 - what a nightmare for various reasons out of my control, and now my graphics card fan runs all the time. https://discussions.apple.com/thread/5254795 :-(

On the good side, I can now start to use C++11!

But the reason I'm here is that moving to XCode 4 got rid of the literally thousands of spurious link warnings that I used to get on XCode each time I built and that my diligent work failed to fix.  Now, I'm within spitting distance of having no warnings at all in my XCode build...

...except that there are rather a lot of warnings still from Juce code, 60 to be precise.

A few of these are C++ warnings, any of which could be fixed in an instant. To be specific, there are warnings regarding four character constants which should be #pragmaed out of the specific files, and in one case Juce redefines a MACRO without #undef'ing it.

But the majority are Objective C errors and I frankly don't understand them at all.

I could easily post my logs, if this was at all useful...


Well, I definitely aim for zero-warnings, but in all my builds there aren't any problems, even with all the flags cranked up  (except for maybe some of the really silly ones). If you take something like the juce demo and let me know which extra flags I'd need to get what you're seeing, then I'd be keen to try it myself.


Interesting, I'm just using the default settings for Juce - or at least I thought I was.

This project is several years old now.  I'll create a new empty project and then copy the XCode flag settings from that into my existing project and I'll see if there are still any failures.


So clearing to the default warning level only has one warning from the Juce side:

/development/juce/modules/juce_audio_basics/juce_audio_basics.cpp:52:10: 'JUCE_USE_VDSP_FRAMEWORK' macro redefined

This seems inevitable if Juce sets a macro in one spot and resets it elsewhere - consider #undef'ing such variables?


It also looks like warnings for implicit 32-bit conversions are turned off.  Is this a good idea for DSP code?


Aside from that, nice and clean!  


Interestingly, my old settings seem to have been suppressing errors looking like this:

ld: warning: direct access in rec::command::CommandMap::getKeys(rec::command::ID) const to global weak symbol std::vector<std::string, std::allocator<std::string> >::~vector() means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

Suspect this has to do with some of my subprojects, I'll fix this myself, but if anyone else here has a Rather Old Juce Project, you might consider resetting your compiler warnings...


Actually, you might consider turning on checking for function prototypes and fixing these errors...

/development/juce/modules/juce_audio_formats/codecs/juce_MP3AudioFormat.cpp:1087:10: No previous prototype for function 'dct36'
/development/juce/modules/juce_audio_formats/codecs/juce_MP3AudioFormat.cpp:1169:10: No previous prototype for function 'dct12'
/development/juce/modules/juce_audio_formats/codecs/juce_MP3AudioFormat.cpp:1256:10: No previous prototype for function 'dct64'
/development/juce/modules/juce_audio_formats/codecs/juce_MP3AudioFormat.cpp:1382:10: No previous prototype for function 'dct64'
/development/juce/modules/juce_gui_basics/native/juce_mac_MouseCursor.mm:30:14: No previous prototype for function 'createNSImage'

You're so close to having everything predeclared!


Oh, and turning on 32-bit warnings resulted in none at all.  Good job!


Thanks! I've had a quick tidy-up session with all warnings cranked up to the max. I guess I missed a few because they were in bits of code like MP3 that I didn't have enabled last time I did some high-warning-level building.