[Update] Google-Maps-iOS-SDK (1.1.0)

[punycode]

No description provided.

[keith]

Looks like there may be some issues with this with 0.16.3 (released yesterday) make sure to update to the newest gem and configure it based on this.

 -> Google-Maps-iOS-SDK (1.1.0)
    - ERROR | The sources did not match any file
    - ERROR | The resources did not match any file
    - ERROR | The preserve_paths did not match any file

Analyzed 1 podspec.

[!] The spec did not pass validation.

[s12chung]

out of curiousity, how do you use this cocoapod? Google-Maps-iOS-SDK1.0.2. I've been trying, but have no ideas.

edit:
i've used other pods before. I get this error for this one:

ld: framework not found GoogleMaps
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[keith]

What version of Cocoapods are you using (pod --version)? In the 0.16.3 update yesterday the handling of zipped archives was changed and the spec may have to be updated.

[s12chung]

updated to 0.16.3 earlier. still not working.

while installing, the Pods/Google-Maps-iOS-SDK directory, looks like there's a file.zip. It unzips it, then the directory is empty.

[keith]

That's my point that version 0.16.3 changes how zipped archives work. The spec probably needs to be changed for this new version.

[s12chung]

ah. sorry. should of read more carefully - frustrating day with rails and ios today. thanks for the quick response!

[keith]

No worries 😄 if @punycode gets this version working with 0.16.3 I'll upgrade the old ones when I have a chance.

[StuClift]

It will work with these values:

  framework_path = 'GoogleMaps-iOS-1.1.0/GoogleMaps.framework'
  s.xcconfig = { 'FRAMEWORK_SEARCH_PATHS' => '"$(PODS_ROOT)/Google-Maps-iOS-SDK/GoogleMaps-iOS-1.1.0/"' }

As the file unzips to the folder GoogleMaps-iOS-1.1.0/ inside Google-Maps-iOS-SDK/

[ryanmaxwell]

@GWStuartClift While it's true that it will work with those values for installing the pod, it still changes how the files are to be imported in the xcode project. Previously it would be #import <GoogleMaps/GoogleMaps.h> and now it has to be #import <Google-Maps-iOS-SDK/GoogleMaps/GoogleMaps.h>.

How can we flatten the downloaded zip, or only preserve paths from the GoogleMaps-iOS-1.1.0/ directory?

[StuClift]

Because the framework search path is set you should be able to just import the framework like previously.

[keith]

Still hitting some errors:

 -> Google-Maps-iOS-SDK (1.0.1)
    - ERROR | The sources did not match any file
    - ERROR | The resources did not match any file
    - ERROR | The preserve_paths did not match any file

[punycode]

The specs will still not work with 0.16.3. Making them bend to the changed behaviour in ZIP flattening would be just an ugly hack in the podspec. As an alternative i have submitted a proposed change to CocoaPods (see CocoaPods/CocoaPods#814). I already upgraded these specs. On older cocoapods (< 0.16.3) versions, they will still work as expected, the hopefully next cocoapods version will incorporate my proposed change and make them work there too.

Update: Also try the cocoapods from this pull request. Though i added a RSpec for the new feature, i would appreciate if someone else tried out the new flattening option for ZIP-files

[StuClift]

The specs should be updated for the new version even if it is not going to be their final state. I don't think the changes needed really fall under 'ugly hack' and whatever ugliness that is there is hidden inside the spec file which is not really designed for the consumer's eyes. The biggest problem with the flattening change is that is highlights the dependency on the source's vendor providing a CocoaPods friendly tag or archive.
Long story short, if we have a fix for the spec on version 0.16.3 then it should be pushed and merged asap or people are not going to be able to use it without downgrading their pod version.
I do think an option to transform directory structures would be desirable however.

[punycode]

I really disagree with this approach. Right now several specs are probably broken, that relied on the previous flattening behaviour. If we start changing the spec now to conform to 0.16.3 behaviour, everyone using a cocoapods version before 0.16.3 will be out of luck too. It won't work on their machines.

One might argue, that those people should simply upgrade their cocoapods, but then perhaps other specs, which we don't know about right now, will break too. A quick and dirty scan for potentially affected Pods gives this result:

~/Projects/Synyx/Opensource/CocoaPods-Specs/ grep -r 's\.source.*:http .*\.zip' **/*.podspec
      50

Should we change all of them until this issue is resolved or simply declare 0.16.3 as broken for ZIP-based pods relying on the flattening behaviour? I really would prefer having a 0.16.4 soon and simply add the :flatten => true option to all those ports. This would be cleaner and simpler than mangling the s.framework_path.

[StuClift]

I don't think its ever a good idea to rely upon the implicit behaviour of the current version of the delivery system, all locations and files should be explicitly defined, this surely is the purpose of a specification; An act of describing or identifying something precisely or of stating a precise requirement.

Fundamentally I agree with what you are trying to achieve and I have no argument against releasing a 0.16.4 with an option to flatten; providing a potentially higher probability of compatibility. However, I can also see how this is not always easy to achieve on a distributed open source project.

[alloy]

The patch in CocoaPods/CocoaPods#814 has been merged and released, people can now use the :flatten => true option with HTTP sources.

[StuClift]

I think the patch from https://github.com/synyx/Specs/commit/68fdd5869e8442983d29bbc872f1e6ebd84f0017 still needs applying now the flatten option is available.

[ryanmaxwell]

@punycode do you have a pull request for those patches?

[ryanmaxwell]

I have manually patched those changes live. Sanity is restored. Thanks everyone.