Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Solution for inhibit_all_warnings! #1572

swizzlr opened this Issue · 7 comments

2 participants


Essentially, prepend every header with #pragma clang system_header.

@orta has recommended I offer it as a plugin, seeing that it is generally not part of the Cocoapods philosophy to touch source files. Given the flagging that occurs and the havoc it wreaked with dtrace files, I'm less precious about this: I see it as a kind of git smudge. I do think it would be an excellent feature to have. If so, where do we put this code to make it happen given the inhibit_all_warnings! flag?

If it is a plugin, can we make it hook into the install process, @irrationalfab, or must it be a kind of command – as @orta suggested, pod silence

A rough implementation in a podfile looks like this. Note that every pod install will prepend another. Ideally it should occur on library install.

post_install do |installer_representation|
  all_source_files = []

  installer_representation.pods.each do |pod|
    pod.source_files.each do |source_file|
      all_source_files << source_file

  header_files = all_source_files.reject { |sf| !(File.extname(sf) == '.h') }

    header_files.each do |source_file|
        original_file = File.realpath(source_file)
        new_file = original_file + '.new', 'w') do |fo|
        fo.puts "#pragma clang system_header\n\n"
            File.foreach(original_file) do |li|
                fo.puts li

        File.rename(new_file, original_file)

Note that this is necessary because appending -w only suppresses warnings on the Pod target. When building your own target your warning levels are included in the pod source files.

Another option is that we make Xcode believe these are system headers – I'm not sure if that will actually work though.


Ideally I would like to see a world where warnings are fixed and the patches contributed back to master. So I'm not overzealous about providing support for silencing them (I do understand that we need to streamline the process of editing a pod though).

Now that the plugin system is shaping up features like these could evolve as a plugin and then merged in CocoaPods if appropriate (which I don't think it is the case for this specific one as it is too much clever :beers:). So I would definitely prefer to see this as a plugin. In the next release we will have basic support but it will not provide hooks. Basically for the moment it would not be possible to implement this.

I'm closing the issue as not actionable in CocoaPods (the tracker is our todo list). Feel free to continue the discussion though.


How could I help put Cocoapods into a state where it would be possible to implement this? What's the architecture goal for plugins?

Give me tests/specs, I will make them pass!


@swizzlr Whoa, what an attitude! :beers: :beers: :beers: Given that I had to take the time to properly detail this: #1578.

Feel free to discuss any mentioned point.


hehehe bonus point for the gif!

@orta this looks like a challenge!



Instead of modifying the source code, we have this in the Pods.xcconfig.

OTHER_CFLAGS = "-isystem${PODS_ROOT}/Headers" "-isystem${PODS_ROOT}/Headers/AFNetworking" "-isystem${PODS_ROOT}/Headers/ReactiveCocoa" "-isystem${PODS_ROOT}/Headers/ReactiveCocoa/ReactiveCocoa" "-isystem${PODS_ROOT}/Headers/ReactiveViewModel"

As opposed to setting them in HEADER_SEARCH_PATHS. I can implement this. May I?

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.