:inhibit_warnings is not applied to subpods #1859

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

Comments

Projects
None yet
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

This comment has been minimized.

Show comment
Hide comment
@shortstuffsushi

shortstuffsushi Mar 13, 2014

👍

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

This comment has been minimized.

Show comment
Hide comment
@gcerquant

gcerquant Mar 26, 2014

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'.

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

This comment has been minimized.

Show comment
Hide comment
@fabiopelosin

fabiopelosin Mar 26, 2014

Member

Thanks for the report!

Member

fabiopelosin commented Mar 26, 2014

Thanks for the report!

@CocoaPodsBot

This comment has been minimized.

Show comment
Hide comment
@CocoaPodsBot

CocoaPodsBot Mar 29, 2014

Issue has been confirmed by @neonichu

Issue has been confirmed by @neonichu

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins Aug 25, 2014

Member

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

Member

segiddins commented Aug 25, 2014

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

@segiddins segiddins closed this Aug 25, 2014

@mtrudel

This comment has been minimized.

Show comment
Hide comment
@mtrudel

mtrudel 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.

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

This comment has been minimized.

Show comment
Hide comment
@poulsbo

poulsbo 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.

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

This comment has been minimized.

Show comment
Hide comment
@gcerquant

gcerquant Oct 24, 2014

I agree too.

I agree too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment