Skip to content

:inhibit_warnings is not applied to subpods #1859

ide opened this Issue Mar 6, 2014 · 8 comments

8 participants

ide commented Mar 6, 2014

For example warnings are not suppressed for this Podfile:

pod 'AWSiOSSDK/STS', '~> 1.7.1', :inhibit_warnings => true

There is some ambiguity if another AWSiOSSDK subpod is imported without suppressed warnings, but I think it would make sense to provide some way to suppress the warnings other than turning them off for all pods.



I noticed this for the first time today (apparently I haven't had a setup where a sub had warnings before). If you use inhibit_all_warnings!, no warnings come through at all, but simply adding :inhibit_warnings => true to one of your pods does not seem to prevent them from coming through from subs.


I can confirm the original issue, and the temporary work-around (use of inhibit_all_warnings!).
Just remember to run pod update after adding this line to the Podfile… (duh!)

In case by the time someone works on this bug the issues in pod 'AWSiOSSDK/STS' have been fixed, an other pod that generate warning in sub pods is pod 'FMDB/SQLCipher'.

@fabiopelosin fabiopelosin added the Defect label Mar 26, 2014
CocoaPods member

Thanks for the report!

@CocoaPodsBot CocoaPodsBot was assigned by ide Mar 29, 2014

Issue has been confirmed by @neonichu

@CocoaPodsBot CocoaPodsBot was unassigned by ide Mar 29, 2014
CocoaPods member

I believe we agreed that inhibit_warnings shouldn't be inherited.

@segiddins segiddins closed this Aug 25, 2014
mtrudel commented Oct 21, 2014

Can I petition to re-open this issue?

I don't see how it's sensible to ignore a user's explicit request to suppress warnings, subspec or not. In my particular (rather common, I imagine) use case, I'm using only the S3 functionality from the AWSiOSSDK/S3 pod, and am faced with the choice between importing only the S3 subspec to keep build times down, or importing the whole thing to have it respect my inhibit_warnings directive.

Again, if I'm explicitly asking cocoapods to ignore errors it shouldn't matter whether I'm making the request of a top level spec or of a subspec; my intention as a user is clear in both cases.

I'm happy to work up a patch for this if there's a reasonable assurance that it'll be accepted.

poulsbo commented Oct 21, 2014

Agree. On my team we use CocoaPods to both manage internal projects, with external dependencies, and to combine those internal projects.

We also have a Zero Compiler Warnings policy.


I agree too.

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.