:vendor_project with multiple pods blocks

[jonmorehouse]

When using 2 pods blocks, (this is often the case when including a gem such as afmotion)... the vendor project doesn't accurately carry through.

The following example shows a situation where the project won't build as a result of the headers_dirs not being accurately passed to the build cycle.

Motion::Project::App.setup do |app|
  # Use `rake config' to see complete project settings.
  app.name = 'test'

  app.pods do

    pod 'pop'

  end

  app.pods :headers_dir => "Headers/{AFNetworking,cineio-ios}" do
    pod 'AFNetworking'
    pod 'cineio-ios'
  end

end

I've tried to fix this with no luck with the following commit: jonmorehouse@7bc3f7e

Any ideas how we can solve this sort of issue?

[jonmorehouse]

So I got a bit further in the issue. Only the first vendored_project is picked up by the rubymotion build cycle. I'm trying to delete that one automatically, so at any given time there is only one vendored cocoapods project: jonmorehouse@a8666b1

This doesn't work from inside of the motion-cocoapods block, but does work by simply adding the following to the bottom of your rake file:

Motion::Project::App.config.vendor_projects.delete_at(0)

[jonmorehouse]

I finally figured out a solution in my latest commit: jonmorehouse@76e2a50

It looks like we need to unvendor the old cocoapods project before adding a new one to successfully uphold the vendor_options. I'm testing this in my own application and it seems to work okay so far, so let me know if I can pull this into a pull-request with some test coverage :)

[alloy]

@jonmorehouse I think that this should be fixed by using something like what @colinta proposes here where AFmotion could add its pod dependencies after those of the user.

I’m closing this for now, but please let me know if I’m overlooking anything!

PS: Sorry for the delay on this 😞