Issue with subspecs and multiple targets #535

Closed
ap4y opened this Issue Sep 20, 2012 · 9 comments

Projects

None yet

5 participants

ap4y commented Sep 20, 2012

Current version includes sources from all subspecs into all targets. For example, such podfile:

pod 'RestKit'
target 'test123Tests', :exclusive => true do
  pod 'RestKit/Testing'
end

will create 2 pod targets with sources from both subspecs (RestKit/JSON and RestKit/Testing) in both targets. Subspec dependencies resolved correctly, targets won't include external pods from wrong subspec.

Owner
alloy commented Sep 21, 2012

Adding to my queue.

@alloy alloy was assigned Sep 21, 2012
ap4y commented Sep 22, 2012

I have found the source of the bug. The problem is with sandbox caching for the local pods. Current implementation caching pods with key defined as key = [spec.top_level_parent.name, platform.to_sym], so it accumulates subspecs in cached local pod instance. I wanted to know is it ok to cache local pods with the full name (something like that key = [spec.name, platform.to_sym])?

Owner
alloy commented Sep 22, 2012

It is important that there is only one LocalPod instance for any top spec at any given time, so I think this would break that behaviour. Seeing as you have a grasp of the actual issue, would it be possible for you to create a failing test?

Owner

@alloy We discussed about this (but I can't find the conversation). I was arguing that we needed to cluster Local Pods, I was supposed to make a failing test but I haven't found the time.

Anyway the issue are two:

  • we have only a Local Pod per platform but we keep we adding to it the subspecs of all the targets (as @ap4y points out)
  • we can have tow local pods for the same pod (one for iOS, one for OS X) if they are both installed and their files differ, only the files of one will be available.

I think that we should cluster the various local pods in a dedicated class so we can use it when we need all the files for a Pod (cleaning, adding to the project). This would have the benefit that this class could store the Pods.xcodeproj uuids so the targets will not have to look for them and the slow Generating supporting files phase could be speed up.

ap4y commented Sep 24, 2012

I have added test, hope it will help. Looking forward for the fix, thanks!

nbransby commented Nov 8, 2012

any suggested workarounds?

In my projects I've created additional podspecs for each needed subspec that only specify the files needed for the subspec.

In the example above, RestKit/Testing would become RestKit-Testing-Workaround. I would copy RestKit.podspec to RestKit-Testing-Workaround.podspec and remove all the non RestKit/Testing parts from the new podspec file.

My project's Podfile would then looks something like this:

pod 'RestKit'
target 'test123Tests', :exclusive => true do
  pod 'RestKit-Testing-Workaround'
end

Not pretty, but it gets the job done.

We have our own spec repo setup, so adding these workaround pods is relatively easy. I'm not sure how to go about it if you don't use your own spec repo.

ap4y commented Nov 8, 2012

It seems like extracting subspecs into it's own spec is the easiest way to solve that problem (as @i-taptera desctibed). It is still possible to disable caching for local pods, but I haven't tested this solution much. So I'm currently prefer separate specs.

Owner

This should be fixed by CocoaPods 0.17. Please reopen if the issue persists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment