How to remove compiler warnings on Pods project?

[yas375]

I wouldn't see warning from some pods in my workspace.

Here is my Podfile:

platform :ios

dependency 'AFNetworking', '0.9.0'
dependency 'JSONKit'
dependency 'ZBarSDK'
dependency 'DTCoreText', :podspec => 'https://raw.github.com/gist/2282812/3844e5d01f562e1cf67f74b966030f2baae94e6d/gistfile1.txt'

And when I build my application Pods project also compiled every time. Is it good? Or I missed something?

Thanks.

[alloy]

Regarding the warnings, can you give me a list of all the build settings required to silence those? It’s probably time to add an option to the Podfile that will set those settings.

Regarding Xcode compiling the library every time, I personally have not noticed this. Afaik the first build takes longer than subsequent ones, but I could be wrong. This would be an Xcode issue, though.

[yas375]

I found one interesting build property: GCC_WARN_INHIBIT_ALL_WARNINGS. If I set it to yes, warnings are disappear. Is it you good solution?

btw, in this twit you have mentioned post_install hook:

@yas375 Hmm, then it works differently than I thought… Add a post_install hook to your Podfile which adds the setting to Pods.xcodeproj?

Does it mean that I could set value for GCC_WARN_INHIBIT_ALL_WARNINGS in my podfile now? And it will be used in Pods project? How I should do this?)

Regarding Xcode compiling the library every time, I personally have not noticed this.

does it mean that in your projects pods compiled only once? What version of xcode and cocoapods do you use?

[alloy]

I found one interesting build property: GCC_WARN_INHIBIT_ALL_WARNINGS. If I set it to yes, warnings are disappear. Is it you good solution?

That sounds like a good enough solution yes. Let’s add this in 0.6.1.

Does it mean that I could set value for GCC_WARN_INHIBIT_ALL_WARNINGS in my podfile now? And it will be used in Pods project? How I should do this?)

Something like this should do the trick:

post_install do |installer|
  installer.project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['GCC_WARN_INHIBIT_ALL_WARNINGS'] = 'YES'
    end
  end
end

(If you are using cocoapods 0.5.1, then build_configurations and build_settings should be camel cased: buildConfigurations and buildSettings.

[yas375]

cool! It works now with this post_install hook! thanks! =)

[fabiopelosin]

I think that the pods should not generate warnings. I think that the warnings should be suppressed by the podspec and the library maintainer should be asked to suppress them.

[yas375]

I agree with you)

[yas375]

@irrationalfab how current version should be working? As I see warnings from Pods not preventing now. Should it be fixed in current version? Or should I open a new ticket for this?

btw, warnings presence could be checked with MTStatusBarOverlay pod. I got at least 3 warnings with this pod.

[fabiopelosin]

The podspec needs to update with the appropriate compiler flags that silence the warnings.

[fabiopelosin]

see compiler_flags - https://github.com/CocoaPods/CocoaPods/wiki/The-podspec-format

[yas375]

Should I do this for all specs where I meet warnings? It's not very clear imho. Than I prefer @alloy's method with post_install hook.

Maybe it will be good to disable pods warnings from podfile in this way:

platform :ios

silent_warnings!

dependency 'MTStatusBarOverlay'

Or maybe better to disable warnings by default and enable only if enable_warnings! call presents in Podfile.

What do you think guys?

[fabiopelosin]

Reasonable point lets see @alloy opinion on this.

[alloy]

Yeah I do think we should be able to just disable them all in one go like with silence_warnings!. This also makes it very easy for a user to see what warnings it actually generates and possibly provide a patch to the author to fix it.

[yas375]

I could do this. But I will have time only on next week (or even after next week). When release 0.6 should be released?

[alloy]

Well, this is more of a feature, so it shouldn't even really be added before 0.6.0, as we should not add features during RCs imo. But any time thereafter is fine, see https://github.com/CocoaPods/CocoaPods/wiki/Release-process.

[yas375]

Ok, assigned to me)

[prnewman]

I get the same compiler warnings as yas375 after adding the ZBarSDK Podspec to my project:

https://github.com/CocoaPods/Specs/blob/master/ZBarSDK/1.2.2/ZBarSDK.podspec

Inhibiting all warnings for the entire Pods project doesn't seem like an ideal solution. I'd prefer contacting the author for a patch before accepting the Podspec.

[fabiopelosin]

After experiencing a bit with warnings I think that the best solution would be to add GCC_WARN_INHIBIT_ALL_WARNINGS by default. Disabling single warnings categories of warnings in the podspecs is a moving target as the default warnings may change and do not represent the view of the author of the library.

To enable the warnings to see if they meet the needs of the standards of the final user we should add the enable_warnings method in the pod file.

@alloy What do you think?

[alloy]

@irrationalfab I don’t think it should be enabled by default. We want users to know that there are in fact warnings, because the user might find that important to know and/or might fix it and submit a patch and they can make in an informed decision.

[fabiopelosin]

@alloy After I gave some thought to comment, I agree with you.

[yvbeek]

alloy's post_install quickfix doesn't seem to work for header file warnings.
Is there a way to turn these off?

I get Multiple declarations warnings from the RestKit and MagicalRecord pods.

[fabiopelosin]

I get Multiple declarations warnings from the RestKit and MagicalRecord pods.

Mhmm, what is you issue specifically?

[alloy]

@Zyphrax Any update on this?

I will add this feature tonight, so it would be nice to have as much info as possible :)

[yvbeek]

@alloy

I'm a bit new to Xcode and objective-C so it might be just my noobism, but:

My project is using a few Pods: RestKit, ActiveRecord and KeychainItemWrapper.
The RestKit project has some warnings about double method declarations in some of the header files. It would be great if I could ignore just the warnings in the Pods project. I tried to disable the warnings on the Pods project manually, but since the headers are used by my project I will still get the warnings.

Probably the best solution is to try and get the maker of the piece of code to resolve the warnings.
However if you guys know a solution to ignore any warnings generated by the Pod code (both headers and implementation) that would be great. Perhaps the ability to specify compiler flags for them?

[alloy]

@Zyphrax Ah, I see. Unfortunately I don’t know a solution for that issue… As headers aren’t compiled directly themselves, there is no way to set compiler flags for them. Your best bet is to submit a patch to the authors with the warnings fixed.

[alloy]

Fixed!

[yas375]

Sorry guys that I promised and didn't implement this(
And thanks for this functionality!

[alloy]

@yas375 Enjoy! :)

[hfossli]

Coult it be possbiel to inhibit warnings on specific pods? Like it is possible with specific files in xcode? http://stackoverflow.com/questions/6921884/xcode-4-how-to-suppress-all-warning-in-specific-source-file

[hfossli]

That would be really great when working with local pods....

[yas375]

@hfossli I didn't try it yet, but documentation says you can inhibit warnings per pod:

pod 'SSZipArchive', :inhibit_warnings => true

Happy coding ;)

[hfossli]

Sweet!! What about in a podspec with dependencies?

[yas375]

@hfossli what do you mean? Could you please give a real example?

[hfossli]

@yas375 Ok. I'll tell you about my setup. :)

AGCore uses AGServices as a pod
AGServices has dependencies to other pods.
When in development of AGCore we are using local path to AGServices.
We want all warnings about AGServices to be revealed in AGCore, but omit any warnings from AGServices' dependencies.

A bit tricky to explain in a simple way...

[hfossli]

So basically if it is possible to write something like this in the podspec that would be sufficient.

Pod::Spec.new do |s|
  s.name = 'AGServices'
  # ...
  s.dependency      'AFNetworking', :inhibit_warnings => true
end

[yas375]

@hfossli I see. Unfortunately I can't help here. Maybe someone else will answer to your question...

[supermarin]

If you inhibit warnings per pod, it's dependencies should also have inhibited warnings (unless you include one of them manually as well).

[hfossli]

@yas375 and @mneorr Well.. It's not pretty, but it works :)

# Lists all pods IVYServices uses to avoid warnings
puts 'Using a hack to avoid warnings from all the pods used directly or indirectly by AGServices'
pod 'Reachability', :inhibit_warnings => true
pod 'AFNetworking', :inhibit_warnings => true
pod 'NSLogger-CocoaLumberjack-connector', :inhibit_warnings => true
pod 'TouchDB', :inhibit_warnings => true
pod 'CouchCocoa', :inhibit_warnings => true
pod 'RestKit', :inhibit_warnings => true
pod 'BlocksKit', :inhibit_warnings => true
pod 'JSONKit', :inhibit_warnings => true
pod 'Overline-BlocksKit', :inhibit_warnings => true

pod 'AGServices', :path => '../services-ios'

I have to know every single pod AGServices is using in order for this to work.

Thanks for the tip!

[hfossli]

If I only could do the opposite? :)

[fabiopelosin]

In an ideal world users of open source libraries would just fix the warnings and submit the patch to the original project, as in 99% of the cases is trivial to do. This is one of the reason why I think that the current support for this feature is more than enough.

[supermarin]

@hfossli well, we might have what you need :)

inhibit_all_warnings! # this will disable all the warnings for all pods
pod 'AGServices', :path => '../services-ios'

[VladislavShchegolev]

In Podfile

post_install do |installer|
    # Pod-Framework
    installer.pods_project.targets.each do |target|
        if target.name == 'Pod-Framework'
            target.build_configurations.each do |config|
                config.build_settings['WARNING_CFLAGS'] ||= ['"-Wno-nullability-completeness"']
            end
        end
    end
    # Pod-Framework - disable nullability completeness warning for all headers
    pod_framework_umbrella_file = File.join(project_pods_root, "Target\ Support\ Files/Pod-Framework/Pod-Framework-umbrella.h")
    pod_framework_umbrella_content = File.read(pod_framework_umbrella_file)
    pod_framework_umbrella_content.prepend(
        <<~END
        #pragma GCC diagnostic push
        #pragma GCC diagnostic ignored \"-Wnullability-completeness\"\n
        END
    )
    pod_framework_umbrella_content.concat(
        <<~END
        #pragma GCC diagnostic pop
        END
    )
    File.open(pod_framework_umbrella_file, "w") { |file| file.puts pod_framework_umbrella_content }
end