Framework pods with static library + test target causes dilemma (Fun with Abstract Targets)

[fatuhoku]

Parse-iOS is a framework-pod.

Let's say I have two targets:

• MyProjLogic static library target
• MyProjLogicTests test bundle target. It depends on MyProjLogic and links against it.

Both of these need Parse support.

I like to express my pod dependencies as groups of 'traits' to apply onto my targets. So I've written my Podfile like so:

# Podfile
...
target :ParseSupport do
  link_with 'MyProjLogic'
  pod 'Parse-iOS'
end

I was expecting this to work. But, actually when compiling the test target it was complaining that <Parse/Parse.h> could not be found.

I try linking the ParseSupport pod-library with MyProjLogicTests as well, as to make the headers available:

...
  link_with 'MyProjLogic', 'MyProjLogicTests' 
...

This causes Duplicate Symbol... errors for Parse objects.

What I learned:

• if I link a framework-pod to a static library, its headers (e.g. <Parse/Parse.h>) are not available to test bundle targets that link to that static library
• if I link the framework-pod to both the static library and the test bundle, then I get linker errors

I cannot think of any solutions other than to to manually set the Header Search Paths manually to point to the framework living under the Pods directory. This will probably get overwritten by Cocoapods every time I run pod install and so this is an undesirable solution.

UPDATE: My solution at the moment is to link Parse explicitly, including all of its dependencies to any target that needs to work with Parse.

This is quite painful because it needs to be done for every target. You might have guessed from the example above, that I also have a couple of targets called MyProjApp and MyProjTasterApp that links against the MyProjLogic static library. For these cases, I get linker errors. I have to manually configure these targets to link against Parse as well.

What should I do?

[plu]

👍

[plu]

Will this be fixed before 0.34.0 will be released?

[kylef]

I try linking the ParseSupport pod-library with MyProjLogicTests as well, as to make the headers available:
link_with 'MyProjLogic', 'MyProjLogicTests'
This causes Duplicate Symbol... errors for Parse objects.

Yes, you are linking it twice, into both the main and the test target. You should only link things into your main target if you want them in tests and in the main target.

At runtime, when testing from the MyProjLogicTests target. Since TEST_HOST is set to the product of the MyProjLogic (main target). All Pods from the MyProjLogic target would be included at runtime.

[kylef]

I can't reproduce any issues where the HEADER_SEARCH_PATHS are not correctly set. Can you share your full Podfile?.

[fatuhoku]

Yes I guess I should be clear: may be I'm a special case (I don't know about you @plu), but I like the separation of App vs. Logic tests even though the concept has been deprecated by Apple.

I don't want my logic tests to load the application bundle because it runs more responsively and executes much faster. And it's fewer moving parts as well.

i.e. this is what my spec target's General tab looks like:

And notably, TEST_HOST is empty.

At runtime, when testing from the MyProjLogicTests target. Since TEST_HOST is set to the product of the MyProjLogic (main target). All Pods from the MyProjLogic target would be included at runtime.

Yes, I realise this is the way 99% (if not 99.99%) of the Cocoapods users test. I don't test this way.

---

Given this environment (and you can call me crazy!), it's easy to produce the issue.

The Podfile that would reproduce the issue is pretty much as it is in the question. Set TEST_HOST to empty and you'll know what I mean.

[fabiopelosin]

@fatuhoku can you show your build phases?

[fabiopelosin]

@segiddins as you confirmed this can you provide the steps to reproduce it?

[fatuhoku]

@fabiopelosin

Build phases of the MyProjLogic target.

Build phases of the MyProjLogicTests target (called *Specs here)

NB: In these screenies I called the Pod grouping ParseFBSupport because I also clumped Facebook-iOS-SDK together with Parse-iOS for my own convenience. This doesn't affect the issue.

[fabiopelosin]

You are linking multiple CocoaPods targets (libPods-Basics.a, libPods-CoreDataSupport) to a single user target in your project and this is not a supported setup (search for abstract target to find current solutions while we provide a full one).

The MyProjLogicTests will not link against the Parse Pod because this target is not hosted by MyProjLogic so it needs to be integrated. Are the symbol issues related to the Parse.framework being in the Link With Binary Libraries build phase?

[fatuhoku]

TL;DR: Cocoapods should express a many-to-many relationship between pod-libraries and targets

@fabiopelosin thanks for your response. Um, the symbol issues are related to Parse.framework NOT being in the Link With Binary Libraries. See my UPDATE on the question above. I think we're very clear that this is a non-standard set up, and I may well be pushing the boundaries of what Cocoapods was intended to do.

I had guessed it was unsupported because nobody does it apart form this guy. But I want to stick with it. Why? Because it works surprisingly well (really, really well) and solves one of my biggest problems, which is having really long pod install times. It avoids duplication. The current Podfile format with one-library-per-target has proven painful to maintain.

I went from having ~100 targets to about ~60 targets in the generated Pods.xcodeproj. That is a big difference in terms of time needed to build, generate dummy files, etc. etc.

Inspite of being unsupported, I'm documenting in this issue, that using this approach, the only thing that doesn't seem to work are

• Frameworks
• and possibly Copy Pods Resources phase (purely judging by the screenie above).

Being able to have multiple abstract pod-libraries link to select targets makes so much more sense. I'd really like to see this become the norm, and for Frameworks to work as we might expect them to under such a scheme.

[krzyzanowskim]

that hit me today. It's kind of regression right? since I have another project when this is configured right.
I'm building library but link pods to test only, however headers are not found.

[fatuhoku]

Abstract targets have been completely broken by 0.34.1 — I'm so sad to have to stick to a development version of 0.33.1 or risk my project not building... :(

[segiddins]

I'm fairly confident this has been fixed, feel free to comment if it hasn't.