Cocoapods: inhibit_all_warnings doesn't work for header files

[Orangenhain]

• [x] I've read and understood the *CONTRIBUTING guidelines and have done my best effort to follow.
  

  Report

What did you do?

• Enabled lots of warnings
• Enabled "treat warnings as errors" on target
• Added Couchbase Lite pod
• Added inhibit_all_warnings! to Podfile
• pod install
• Tried to compile workspace
  

  What did you expect to happen?

Expected the project to compile without issues.

What happened instead?

The headers that are included when doing #import <CouchBaseLite/...> generate a few warnings (handled as errors), which stops the project from compiling.

This isn't an issue with CBL, but with the fact that even when I explicitly ask Cocoapods to inhibit warnings for a pod (or all of them), their headers can still be a source for warnings.

What I ended up doing was specifying --system-header-prefix=CouchbaseLite as part of _OTHER_CFLAGS_ - mentioned in http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-in-system-headers - maybe this could be an option for other pods as well.

[neonichu]

Might be possible for us to use this, but we'll have to investigate any possible side-effects of making Pod headers system headers. AFAIK, we are already using -isystem, though, which should have the same effect.

[Orangenhain]

Yes, -isystem is used & that _should_ keep warnings from showing up, but at least in my case that doesn't help. But that doc also states:

but this can be overridden in several ways

My guess would be that either there is a setting that still makes this warning show up for headers from -isystem paths, or Xcode doesn't find the headers (just) via that directive.

[Orangenhain]

Something similar happens when you're using modules:

1. new project
2. enable warnings as errors
3. enable relevant warning, e.g. -Wnewline-eof
4. add _MASShortcut_ pod & enable use_frameworks! in Podfile
5. add @import MASShortcut; to AppDelegate.m

Result:
Project fails to compile, because the module header files generate a warning, and that's treated as an error.
In this case the previous workaround (--system-header-prefix=) doesn't seem to work.

After reading http://clang.llvm.org/docs/Modules.html#module-declaration I've found two things that do work:

• adding #pragma clang system_header to the start of the module's umbrella header
• adding the system attribute to the modules .modulemap file, like so:

framework module MASShortcut [system] {

[Orangenhain]

Didn't want to close that ... my bad.

[guillaumealgis]

I had the exact same problem for months, thanks @Orangenhain for taking the time to open this issue.

I put a minimal project exhibiting this there : https://github.com/guillaumealgis/CocoaPodsWarnings.
This uses the pod Shimmer, which will raise warnings when -Wdocumentation is enabled.

I found that replacing -iquote with -isystem silenced the warnings on my test project:

diff --git a/lib/cocoapods/generator/xcconfig/aggregate_xcconfig.rb b/lib/cocoapods/generator/xcconfig/aggregate_xcconfig.rb
index fb0e7b0..3d92dd9 100644
--- a/lib/cocoapods/generator/xcconfig/aggregate_xcconfig.rb
+++ b/lib/cocoapods/generator/xcconfig/aggregate_xcconfig.rb
@@ -111,7 +111,7 @@ module Pod
             end
             build_settings = {
               # Make framework headers discoverable by `import "…"`
-              'OTHER_CFLAGS' => '$(inherited) ' + XCConfigHelper.quote(framework_header_search_paths, '-iquote'),
+              'OTHER_CFLAGS' => '$(inherited) ' + XCConfigHelper.quote(framework_header_search_paths, '-isystem'),
             }
             if pod_targets.any? { |t| !t.should_build? }
               # Make library headers discoverable by `#import "…"`

I'd open a PR, but:

1. I'm not quite sure why iquote is used for frameworks, while isystem is used for static libs, and I'm afraid of breaking something (maybe @mrackwitz could help here, it seems from the logs that you were the one introducing this in a072f3e56163e8c43dc419ba3678686564abf41d :) )
2. I'm having a _really_ hard time setting up Rainforest on my machine (already spent a good 8h on it), and thus can't run the tests to see if this change messes things up.

I'm willing to put more work on this as this is frustrating to always have a ~10 warnings in my project coming from the pods headers, but I'm not aware enough of the internals of CocoaPods or the subtleties of clang options to understand what the source of the problem is. So any help will be very much appreciated! Thanks!

[fonkadelic]

Any news on this? Super annoying when treating warnings as errors.

[benasher44]

@guillaumealgis if you want to test your change, you can get away with just cloning CocoaPods and then running bundle install and then run bundle exec rake spec to run all of the tests.

[benasher44]

Someone could also test setting GCC_WARN_INHIBIT_ALL_WARNINGS instead of what we currently do, which is set -w for every source file.

[guillaumealgis]

Thanks for the help @benasher44!

Some tests failed, but I think this is to be expected, and after replacing iquote by isystem where it's needed, things are starting to look good.
I'm failing to pass the examples though:

Running examples
--------------------------------------------------------------------------------

Example: examples/AFNetworking Example
    Installing Pods
    Building scheme: AFNetworking Example
    Building scheme: AFNetworking iOS Example
Example: examples/Alamofire Example
    Installing Pods
    Building scheme: iOS Example
rake aborted!
2016-11-01 20:36:10.470 xcodebuild[41045:781956] [MT] PluginLoading: Required plug-in compatibility UUID DA4FDFD8-C509-4D8B-8B55-84A7B66AE701 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/Alcatraz.xcplugin' not present in DVTPlugInCompatibilityUUIDs
Build settings from command line:
    ONLY_ACTIVE_ARCH = NO

=== CLEAN TARGET Alamofire OF PROJECT Pods WITH CONFIGURATION Debug ===

Check dependencies
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.

** CLEAN FAILED **


The following build commands failed:
    Check dependencies
(1 failure)
=== BUILD TARGET Alamofire OF PROJECT Pods WITH CONFIGURATION Debug ===

Check dependencies
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.
“Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly.

** BUILD FAILED **

Is this to be expected as I'm running Xcode 8.1? It looks like Travis is still using 7.3.

[benasher44]

Hi @guillaumealgis! Sorry for the delay, and I appreciate you working on a fix! If you update your branch with master, I believe we're using a more up-to-date Xcode now.

[guillaumealgis]

Hi @benasher44 thanks for pinging me. I opened PR https://github.com/CocoaPods/CocoaPods/pull/6401 fixing this.

Please let me know if this looks good to you 👍

[diegorozen]

Hello, do we have any updates on this fix or a workaround? Thanks!

[intspt]

still exists in 1.2.1

[guillaumealgis]

@diegorozen @intspt still working on a fix in https://github.com/CocoaPods/CocoaPods/pull/6401. All help welcome, I'm struggling to find time to push this forward 👍

[RishabhTayal]

Any updates on this fix? I have tried this option. It sets the flag in the pod targets but still getting error while compiling.

[AlexRablau]

I would also love a fix to this. I am using the Protobuf pod and it generates hundreds of warnings in its header files. Nothing seems to work to inhibit them!

[paulb777]

@AlexRablau The Protobuf warnings have been fixed in a recent release

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[guillaumealgis]

Still working in a fix in https://github.com/CocoaPods/CocoaPods/pull/6401 Stale Bot ;)

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[guillaumealgis]

Not staled. Waiting for maintainers input in #6401 (I'll rebase on top of master).

[dennishahn]

Still seeing the same issue in Version 1.4

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[guillaumealgis]

Still waiting for activity on #6401.

[alexandre-g]

I have no idea what I'm doing, but inserting
#pragma clang diagnostic ignored "-Weverything"
or
#pragma GCC system_header
before the #include ... in the bridging header/objc import hides the warnings for me while waiting for this..

[bolee]

inhibit_all_warnings! still not working for header files, someone will fix it?

[guillaumealgis]

@bolee this is in progress. See https://github.com/CocoaPods/CocoaPods/pull/6401