Skip to content

:inhibit_warnings is not applied to subpods #1859

Closed
ide opened this Issue Mar 6, 2014 · 8 comments

8 participants

@ide
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.

@shortstuffsushi

:+1:

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.

@gcerquant

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
@fabiopelosin
CocoaPods member

Thanks for the report!

@CocoaPodsBot CocoaPodsBot was assigned by ide Mar 29, 2014
@CocoaPodsBot

Issue has been confirmed by @neonichu

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

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

@segiddins segiddins closed this Aug 25, 2014
@mtrudel
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
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.

@gcerquant

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.