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)
In my experience, XCode 3.x seems to only show the warnings for files that have actually been compiled in the most recent build, so if you build the project, modify a single file and then build the project again, you'll only see the warnings for the modified file. I generally find this to do more harm than good (especially since in Objective-C it's only a warning to call a selector that doesn't exist!) — and thankfully it's fixed in XCode 4 — but in your case in might be useful.
However, for various reasons you might want to consider putting the third-party code into a Framework. This wouldn't automatically suppress the warnings (although it might make it easier to suppress them) but it would mean that the third-party code was compiled into a library and therefore wasn't part of your normal compile cycle.
Turning off warnings on a per file basis is super simple. All that is required is a compiler flag. Here’s the step by step process.
Open the Project Navigator in Xcode
Click on the Project icon at the very top of the navigator
In the resulting detail pane select the target that you are working
with
Select “Build Phases”
Expand “Compile Sources”
In the list locate the file that you’re interested in
Double click the column under the “Compiler Flags” column next to
your file
Add a -w to the resulting dialog
Click “Done”
Build your now warnings free project
here is the reference link
http://blog.bluelightninglabs.com/2011/12/suppressing-xcode-warnings-on-a-per-file-basis/
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.)
Related
When I build/enter play mode in the Unity IDE, many warnings clutter the console window that have been generated by script compilation of 3rd-party assets. How can I disable or hide the console warnings from specific assets without making changes to those assets?
I anticipate people righteously howling about how I need to fix the warnings instead of sweeping them under the rug. But to those folks, please consider...
The code is in 3rd-party assets--not mine. Typically, no upgrade on the asset is available that would fix the messages, and I've reviewed the messages and judged them to be benign. I realize the value of warnings, but I don't want to dig into 3rd-party code to fix the warnings. I'm also reluctant to change the code in these assets because it essentially gives me a local fork. And then future updates on the asset from the 3rd-party will need to be hand-merged against my local updates. That's time-consuming and introduces risk.
Two years later, I can answer my own question. :)
Create .asmdef files such that third party assets are in one manifest, and all project code is in a separate .asmdef. So in my project, I keep the 3rd-party assets just under Assets with project one level down.
Assets (folder)
thirdPartyAssets.asmdef
...other files and folders...
Project (folder)
project.asmdef
...other files and folders
This basically "disables" warnings from 3rd-party assets by simply not building them. You will still see 3rd-party build warnings if those assets change or a clean build is made.
The original question was how to disable for specific assets, so I'll note that it's possible to arrange the .asmdefs to include/exclude assets in different groups. And simply putting an .asmdef into the folder of one asset that warning-spams, will cause that single asset's warnings not to be shown except for the cases I described in the previous paragraph.
Put the plugin into its own folder and make an assembly definition if there isn't one already.
Then you need to create a csc.rsp text file alongside the assembly definition
Edit this csc.rsp and add this line
-warn:0
This will set the warning level to 0 (no warnings) for that assembly only.
see https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/errors-warnings
Thank you to both Erik Hermansen and Adam B for providing solutions.
I went with Erik Hermansen's solution, but modified it slighty, sort of the other way around :) :
moved all third party stuff into a folder Assets/ThirdParty, and created Assets/ThirdParty/ThirdParty.asmdef
kept my own stuff at top level, and created Assets/MyAssembly.asmdef
Note that you probably have to add some references to each assembly:
MyAssembly.asmdef:
ThirdParty.asmf
Unity.TextMeshPro
ThirdParty.asmdef:
Unity.TextMeshPro
(maybe some others, depending on your own project)
I'm new to iOS and trying to use RestKit.
I'm getting a 'sigabrt' exception during Singleton instantiation dealing with the use of autoRelease.
I noticed that RestKit uses memory management keywords that are not allowed in iOS projects w/ Automatic Reference Counting (ARC) enabled, could this be an issue?
Anyone encountered anything similar?
I'm surprised you were able to get the project to compile with those keywords.
You will need to use the linker flag -fno-objc-arc in the Compile Sources section of your Build Settings for all RestKit files, or include it as a project that does not use ARC (a much better approach).
Refer to the RestKit installation docs for help on this: https://github.com/RestKit/RestKit/wiki/Installing-RestKit-in-Xcode-4.x . Installing as a git submodule is the way to go imho.
You can easily add the library to a project that use automatic reference counting (ARC) by following the steps below.
Add the Rest kit files to your project.
Go to your project settings, select your application's target(s) and click the "Build Phases" tab.
Expand the section named "Compile Sources".
Select all the files from the RestKit library
Hit Enter to edit all the files at once, and in the floating text-box add the -fno-objc-arc compiler flag.
Thanks.
OK - found the problem: it seems the '-ObjC -all_load' key disappeared, I thoroughly followed RestKit's install instructions but this seemed to have slipped somehow - jshin thanks for making me look through the installation help again :)
Coming from .NET world I have to say XCode/ObjectiveC feel extremely archaic in comparison, just adding a library is a 10 page manual and not to mention the exception that made no sense what's so ever or gave any useful info - but then again this is coming from someone who's new to iOS :)
I have an Iphone app that used the excellent ABContactHelper library origionally written for by Erica Sedun and released on github
Now with the release of XCode4 and Reference Counting support, it causes lots of errors. I have looked at the forks on github, but none seem to have updated to XCode 4 with Reference Counting. I am trying to update it myself but its slow and error prone. I have tried the automatic refactoring support, but to no avail.
Does anyone know of an alternative AddressBook wrapper that provides a simple interface for interacting with the IPhone AddressBook?
In your ARC-enabled project, you can selectively disable ARC for the AddressBook wrapper files by setting the -fno-objc-arc compiler flag for those files.
Add compiler flags in Targets -> Build Phases -> Compile Sources. Enter the compiler flag by double-clicking on the right column of the row under Compiler Flags.
Dealing with ARC/non-ARC issues is a pain in the butt, and I've found that letting CocoaPods handle these problems for me is the way to go. Simply list ABContactHelper as a pod dependency and you're done. Many of the most popular libraries are already there, but if yours isn't, it's really easy to add it.
http://cocoapods.org
TL;DR Version:
This question has arisen due to the fact that I have multiple frameworks (which I have built) and a client project that uses said frameworks. Now, when I open up the client project and try to debug into the framework, it doesn't work.
However, if I have the project associated with the framework open, then debugging appears to work (though there are some weird issues with breakpoints I don't see being triggered).
I have looked at Apple's docs, and perhaps the answer is buried there somewhere, but I couldn't find it on a skim of the Xcode Debugging Guide.
Long Version:
The reason this question is important to me is that a coworker and I had a disagreement about how headers are imported in the frameworks we build.
I have a tendency to use framework headers (with client apps) in the fashion:
#import "FrameworkA/HeaderA.h"
#import "FrameworkB/HeaderB.h"
He, on the other hand, favors importing the framework headers (with client apps) like this:
#import "HeaderA.h"
#import "HeaderB.h"
and specifying the header search paths in the build target of the client application.
Complicating matters further is the fact that some of these frameworks have interdependencies. For example, FrameworkB has headers from FrameworkA referenced in his format:
#import "HeaderA.h"
His argument for doing this is that debugging only works if we import headers this way. It seems dubious to me that there would be a relation between header importing style and debugging, but I am not really certain how XCode chooses the file to link to during debugging, hence the question.
Thanks in advance for any assistance with this query.
you add project references to the target, and make sure Xcode knows where to find the debug symbols.
#import <FrameworkA/HeaderA.h>
that's the way to go (for internal and external declarations). the reason? the other approach is more likely to cause issues as libraries evolve. the additional qualification disambiguates any case (unless of course there are two FrameworkA/s in your search path), it's best to qualify the file explicitly now, rather than when your clients tell you they cannot use your library with other libraries, or that they can only use them in some conditions. then you have to go fix the issues and reship (this stuff has a way of happening at inconvenient times =p). it's one simple measure to ensure you've developed a robust interface.
perhaps the most important part that people overlook is the location of the products: use a customized central build location for your targets -- many people use the default location, which is by the xcodeproject. otherwise, Xcode may not be able to locate debug information.
finally, debugging complex projects in Xcode can be quite... let's call it 'problematic'. So don't expect the debugging experience to be perfect, even if you've configured everything correctly. all the more reason to integrate assertions and unit tests into your development cycle early on with Xcode. truth is, the debugger may be useless no matter how hard you try - this is not a new issue. hopefully LLDB will improve our debugging experiences.
good luck
I've looked at Microsoft's MSDN and all around the web, but I still haven't been able to get a really good idea of what it is.
Does it mean the completed program loads DLLs at different times during its execution, as apposed to all at once upon launch?
Am I totally way off? :)
Linking involves packaging together all of the .obj files built from your source files, as well as any .lib files you reference, into your output (eg .exe or .dll).
Without incremental linking, this has to be done from scratch each time.
Incremental linking links your exe/dll in a way which makes it easier for the linker to update the existing exe/dll when you make a small change and re-compile.
So, incremental linking just makes it faster to compile and link your project.
The only runtime effect it might have is that it may make your exe/dll slightly bigger and slower, as decribed here:
http://msdn.microsoft.com/en-us/library/4khtbfyf.aspx
Edit: As mentioned by Logan, incremental linking is also incompatible with link time code generation - therefore losing a possible performance optimization.
You may want to use incremental linking for debug builds to speed development, but disable it for release builds to improve runtime performance.
Delay loaded DLLs may be what you are thinking of:
http://msdn.microsoft.com/en-us/library/151kt790.aspx
Also, quite importantly, incremental link is a prerequisite for Edit&Continue - possibily to edit your code and recompile it on the fly, without restarting.
So it is a good thing to have on debug builds, but not release builds.