Can I have different warning levels for different folders in Xcode? - xcode

I compile my Xcode projects with very high warnings settings. Sometimes, I have to use third-party frameworks that are distributed as source (rather than as a framework). These frameworks often throw a lot of warnings.
Is there a way to turn off warnings for these folders? I want the stricter level for my own code, but don't care if third-party code violates my warnings level.
Basically, I don't want to see 67 warnings every time I build.

You're looking for this:
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
Flags can be found here: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Warning-Options.html
Just replace the -W... with whatever you want to ignore.

Related

What does BII_IMPLICIT_RULES_ENABLED do when switched on or off in CMakeLists.txt?

I was wondering about the BII_IMPLICIT_RULES_ENABLED flag which I had switched off in one of my CMakeLists.txt files, in order to get an OpenGL related block to compile on a Mac, following a suggestion from biicode. This setting is still there and everything works perfectly, but I would like to find out more about it. Could someone explain what it does exactly?
Thanks!
BII_IMPLICIT_RULES_ENABLED activates the addition of system libs to the target that has included certain headers. For example, if your code contains an:
#include "math.h"
And you are in *nix systems, then the library "m" (libm) will be added to your target via TARGET_LINK_LIBRARIES.
You can see the headers that are processed in your cmake/biicode.cmake file, in the HANDLE_SYSTEM_DEPS
My recommendation: Put it to False whenever possible, and handle the required system libs yourself, exactly what you have done. It is something that will be deprecated soon, or at least set to False by default to new projects. This option sometimes causes troubles, if something fails or there is a bug in biicode.cmake, e.g. in the past it tried to add libm to targets also in windows. It will be gradually deprecated and probably substituted by some CMake macros hosted (as in http://www.biicode.com/biicode/cmake) that could be used by users if they decide to, but not automatically as it is done now.

Make Xcode ignore LLVM build warnings in 3rd party project

I have a third party project in my Xcode workspace (it's a dependency for my main project) and I want Xcode to ignore all build warnings from that third party project.
Preferably I'd like to ignore all build warnings for the Vendor/* group in my project since that's where I put all my third party code.
Possible?
Yes, it's possible, but only if you compile the third-party files in a separate target. This way, you can set different compiler flags.
Let's say your main target is an application. You defined your build settings, as well as the compiler warning flags.
Now you want to use some third-party sources. You import them into your project, but they generate warning. You could of course change your main target's settings, but I'm pretty sure you want to keep your own settings.
Simply create an additional target in your project, which is a static library.
Removes the third-party files from your main target, and add them to the library.
In your main target's build phases, link your application with the static library.
This way, you'll be able to use the third-party code in your application, while having different compiler settings for third-party code.
It is possible on a per file basis, see the blog entry at http://blog.bluelightninglabs.com/2011/12/suppressing-xcode-warnings-on-a-per-file-basis/
To summarize: Use the compiler flags on the “Build phases” tab.
Go to Build Phases > Compile Sources. Optionally filter the list. Select the ones you want to exclude and then double click in the blank area under the Compiler Flags column. Add -w and hit return:
if you are worried only about warning via inclusion, then you can wrap your include statements in this:
#pragma clang diagnostic push
// in reality, you will likely need to disable *more* than Wmultichar
#pragma clang diagnostic ignored "-Wmultichar"
#include <TheirLibrary/include.h>
#pragma clang diagnostic pop
if you also want to disable the build warnings it generates, then you can use -w or GCC_WARN_INHIBIT_ALL_WARNINGS = YES for the third party target which you link to or bundle.
ideally, you will file reports with the vendor if it is closed. if it is open, then maybe you should just patch it yourself.

How can I convince Xcode to emit a duplicate symbol linker error?

Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.

How do I disable Xcode static analysis (Clang) messages?

I'd like my Xcode project to go through a Build And Analyze step without generating any errors, warnings, or static analysis messages. A problem with this is that my project includes libraries that generate (possibly innocuous) warnings and static analysis messages.
I can't find a way to disable specific Clang warnings so that "my" code builds with zero issues. Is this possible?
I wasn't able to find any way to do this, and filed a bug against Clang. The team seems to want to add this functionality, but it's not there yet.
The bug is: http://llvm.org/bugs/show_bug.cgi?id=7296
Also, one can use a __clang_analyzer__ macro to ifdef out any code that one doesn't want Clang to process.
The Build and Analyze step is clang - thats the "analyze" part. It wouldn't make sense to analyze your code and not have clang tell you about issues it find. That's like going to a car wash and telling them not to touch the car.
From talking to the guy that wrote clang at WWDC, it is extremely unlikely that anything it identifies as an issue is actually not. If you think you have some examples of code that works fine but clang complains, please file a bugreport with example code so Apple can fix that.
You can disable some compiler warnings through the use of flags, but not all of them are an option.

Disable all gcc warnings

I'm working on a project that will read compiler error messages of a particular variety and do useful things with them. The sample codebase I'm testing this on (a random open-source application), and hence rebuilding frequently, contains a few bits that generate warnings, which are of no interest to me.
How do I disable all warnings from GCC, so I can just see error messages if there are any?
-w is the GCC-wide option to disable warning messages.

Resources