Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Solution for inhibit_all_warnings! #1572

Closed
swizzlr opened this Issue · 7 comments

2 participants

@swizzlr

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

  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'

        File.open(new_file, 'w') do |fo|
        fo.puts "#pragma clang system_header\n\n"
            File.foreach(original_file) do |li|
                fo.puts li
            end
        end

        File.rename(new_file, original_file)
    end
end
@swizzlr

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.

@fabiopelosin

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.

@swizzlr

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!

@fabiopelosin

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

@fabiopelosin

hehehe bonus point for the gif!

@orta this looks like a challenge!

@swizzlr

ANOTHER SOLUTION HAS EMERGED.

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.