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.
:inhibit_warnings => true
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'.
Thanks for the report!
Issue has been confirmed by @neonichu
I believe we agreed that inhibit_warnings shouldn't be inherited.
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.
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.