Cocoapods: Empty resource bundles fail pod target to lint / build

[mrackwitz]

Report

What did you do?

1. Define a podspec with resources bundles, whose wildcards don't match any actual file.
2. Run pod lib lint.
   

   What did you expected to happen?

One of these scenarios:

1. that the lint fails gracefully and points me to the wrong resources bundles definition in my podspec
2. that the lint and the build succeeds, because we just don't generate a resource bundle target, if it doesn't match any files, but the linter should still warn at least in that case and point me to the wrong resources bundles definition in my podspec
3. that the lint and the build succeeds, because the pod target generator adds some dummy file to the resource bundle target to trick Xcode into scaffolding the file structure for targets without any files and could be deleted then by a shell script build phase later on

What happened instead?

A resources bundle target is created, but empty, and is not actually build by Xcode or at least doesn't generate a build artifact which can be embedded, so that the build of the pod target fails subsequently due to missing this build product. This is not shown by default when running the linter and appears hidden behind a failure of xcodebuild. e.g.

- ERROR | [OSX] xcodebuild: Returned an unsuccessful exit code. You can use `--verbose` for more information.

In verbose mode:

CpResource /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/build/Release/RxRealm.bundle /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/build/Release/RxRealm.framework/Versions/A/Resources/RxRealm.bundle
    cd /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/Pods
    builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -strip-debug-symbols -strip-tool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -resolve-src-symlinks /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/build/Release/RxRealm.bundle /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/build/Release/RxRealm.framework/Versions/A/Resources
error: /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/build/Release/RxRealm.bundle: No such file or directory

** BUILD FAILED **
The following build commands failed:
    CpResource /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/build/Release/RxRealm.bundle /var/folders/64/vmn77sp112xdn5np6mjtwxfw0000gn/T/CocoaPods/Lint/build/Release/RxRealm.framework/Versions/A/Resources/RxRealm.bundle

Notes

2. (and 3., but 😨) have the advantage that it would support podspecs, which rely on bootstrapping the contents of the resource bundle by a prepare_command, which could yield empty contents as a possible outcome.

[neonichu]

I'd prefer 1. as it would be similar to our handling of source_files not matching anything.

[icanzilb]

Part of the issue is that the default Pod template includes definition for bundle resources. It happened to me that I just leave these lines in my podspec and never realize why the lint fails.

Here's the relevant part of the default spec:

https://github.com/CocoaPods/pod-template/blob/master/NAME.podspec#L33

If you don't manually remove those lines and don't have resources, lint will fail

[icanzilb]

I'd prefer nr.1 as well, and we spawn a separate issue to comment the lines about resource_bundle in the default pod spec - just the way it is for frameworks, dependancies, etc.

[segiddins]

This already appears to be done? https://github.com/CocoaPods/CocoaPods/blob/master/lib/cocoapods/validator.rb#L521-L523

[mrackwitz]

@segiddins: I guess, that didn't triggered because of the .gitkeep file in the template.

[neonichu]

I think the issue will rather be that the resource_bundles hash isn't empty itself, but values in it will be empty arrays.

[mrackwitz]

@neonichu: Yeah, you're right. We should just implement a custom validate method for resource bundles and remove it from the FILE_PATTERNS array.

[icanzilb]

@mrackwitz which of the 3 solutions originally proposed would that be?

[mrackwitz]

@icanzilb: Solution 1.