Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

How to remove compiler warnings on Pods project? #209

Closed
yas375 opened this Issue · 40 comments

7 participants

@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
Owner

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
Owner

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 yas375 closed this
@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
Owner

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

@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
Owner

Reasonable point lets see @alloy opinion on this.

@alloy
Owner

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.

@alloy alloy reopened this
@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
Owner

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 yas375 was assigned
@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
Owner

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
Owner

@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
Owner

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

@Zyphrax

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
Owner

@Zyphrax Any update on this?

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

@Zyphrax

@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
Owner

@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
Owner

Fixed!

@alloy alloy closed this
@yas375

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

@alloy
Owner

@yas375 Enjoy! :)

@fabiopelosin fabiopelosin referenced this issue from a commit
@fabiopelosin fabiopelosin Merge branch 'master' into pod_update
* master: (21 commits)
  Release 0.13.0
  Changelog
  [UserProjectIntegrator] Don't warn about overridden build settings if silent.
  [OpenURI] Reworked support for http to https redirects.
  [Podfile#podspec] Changelog and added disabled tests.
  [Podfile] Added Podfile#podspec.
  [Changelog]
  [UserProjectIntegrator] Check if the xcconfig files is overridden.
  [Linter] Detect warning disabling compiler flags.
  [OpenURI] Support for unsafe redirects.
  [inhibit_all_warningsDon't affect the final project.
  Release 0.12.0
  [Examples] Update RKTwitter Podfile.lock
  [CHANGELOG] Add entry about namespacing subspecs in Pods.xcodeproj
  [CHANGELOG] Update for 0.12.0
  [Project] Namespace subspecs in groups.
  Document Podfile#inhibit_all_warnings!
  Add Podfile#inhibit_all_warnings! to silence warnings, but not by default. #209
  Changelog
  "[Specification] Allow to require_arc in subspecs."
  ...
cfc0d54
@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
Collaborator

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
Collaborator

@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'
@fabiopelosin fabiopelosin referenced this issue from a commit
@fabiopelosin fabiopelosin Merge branch 'master' into pod_update
* master: (21 commits)
  Release 0.13.0
  Changelog
  [UserProjectIntegrator] Don't warn about overridden build settings if silent.
  [OpenURI] Reworked support for http to https redirects.
  [Podfile#podspec] Changelog and added disabled tests.
  [Podfile] Added Podfile#podspec.
  [Changelog]
  [UserProjectIntegrator] Check if the xcconfig files is overridden.
  [Linter] Detect warning disabling compiler flags.
  [OpenURI] Support for unsafe redirects.
  [inhibit_all_warningsDon't affect the final project.
  Release 0.12.0
  [Examples] Update RKTwitter Podfile.lock
  [CHANGELOG] Add entry about namespacing subspecs in Pods.xcodeproj
  [CHANGELOG] Update for 0.12.0
  [Project] Namespace subspecs in groups.
  Document Podfile#inhibit_all_warnings!
  Add Podfile#inhibit_all_warnings! to silence warnings, but not by default. #209
  Changelog
  "[Specification] Allow to require_arc in subspecs."
  ...
5233435
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.