Cocoapods: App with multiple nested targets doesn't propagate nested dependencies properly to app

[lilyball]

• [X] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

When upgrading from CocoaPods 1.5.3 to 1.6.1, dependencies from nested targets aren't propagating to the app correctly anymore. In my testing it appears that if the app has multiple nested targets, it only propagates dependencies from one of them. CocoaPods 1.5.3 correctly propagated dependencies from all of them.

What did you do?

pod install after upgrading CocoaPods to 1.6.1.

What did you expect to happen?

Dependencies should be set up properly and my app should compile.

What happened instead?

My host app target lost access to dependencies declared by its embedded framework target.

For example, in the sample project below, upgrading from CocoaPods 1.5.3 to 1.6.1 produces the following xcconfig diff:

diff --git a/Pods/Target Support Files/Pods-DepTest/Pods-DepTest.debug.xcconfig b/Pods/Target Support Files/Pods-DepTest/Pods-DepTest.debug.xcconfig
index e803c35..a59d17d 100644
--- a/Pods/Target Support Files/Pods-DepTest/Pods-DepTest.debug.xcconfig    
+++ b/Pods/Target Support Files/Pods-DepTest/Pods-DepTest.debug.xcconfig    
@@ -1,11 +1,9 @@
-ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES
 CODE_SIGN_IDENTITY =
-FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/PMHTTP" "${PODS_CONFIGURATION_BUILD_DIR}/PMJSON" "${PODS_CONFIGURATION_BUILD_DIR}/libcmark_gfm"
+FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/libcmark_gfm"
 GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
+HEADER_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/libcmark_gfm/libcmark_gfm.framework/Headers"
 LD_RUNPATH_SEARCH_PATHS = $(inherited) '@executable_path/../Frameworks' '@loader_path/Frameworks'
-OTHER_CFLAGS = $(inherited) -iquote "${PODS_CONFIGURATION_BUILD_DIR}/PMHTTP/PMHTTP.framework/Headers" -iquote "${PODS_CONFIGURATION_BUILD_DIR}/PMJSON/PMJSON.framework/Headers" -iquote "${PODS_CONFIGURATION_BUILD_DIR}/libcmark_gfm/libcmark_gfm.framework/Headers"
-OTHER_LDFLAGS = $(inherited) -framework "PMHTTP" -framework "PMJSON" -framework "libcmark_gfm"
-OTHER_SWIFT_FLAGS = $(inherited) "-D" "COCOAPODS"
+OTHER_LDFLAGS = $(inherited) -framework "libcmark_gfm"
 PODS_BUILD_DIR = ${BUILD_DIR}
 PODS_CONFIGURATION_BUILD_DIR = ${PODS_BUILD_DIR}/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
 PODS_PODFILE_DIR_PATH = ${SRCROOT}/.

Notice how PMHTTP and PMJSON were removed.

CocoaPods Environment

I've reproduced this in a sample app and attached the environment for that:

Stack

   CocoaPods : 1.6.1
        Ruby : ruby 2.5.3p105 (2018-10-18) [x86_64-darwin17]
    RubyGems : 2.7.6
        Host : Mac OS X 10.14.3 (18D109)
       Xcode : 10.1 (10B61)
         Git : git version 2.17.2 (Apple Git-113)
Ruby lib dir : /nix/store/92ypjl979zimr8jvwachqdjg1n7bcvir-ruby-2.5.3/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ eec1cdd10cf1ca375ab5e57d7a7c1571e5df23db

Installation Source

Executable Path: /nix/store/p735bjm3n2smkvhwzfwpyr1k3klkz177-cocoapods-1.6.1/bin/pod

Plugins

cocoapods-deintegrate : 1.0.3
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.3.1
cocoapods-try         : 1.1.0

Podfile

# Uncomment the next line to define a global platform for your project
platform :osx, '10.14'
workspace 'DepTest.xcworkspace'
use_frameworks!

target 'DepTest' do
  project 'DepTest.xcodeproj'
end

target 'DepTestKit' do
  project 'DepTestKit/DepTestKit.xcodeproj'

  pod 'PMJSON'
  pod 'PMHTTP'
end

target 'mylib' do
  project 'DepTest.xcodeproj'
  pod 'libcmark_gfm'
end

Project that demonstrates the issue

DepTest.zip

I didn't include the Pods dir so you'll have to run pod install.

[lilyball]

I just reproduced it by adding a second embedded target (this time a static library). After installing it only propagated the dependencies from the second target to the host app. I'll update this ticket accordingly.

[lilyball]

Description updated and sample project attached.

The sample project has one embedded framework from a nested project, and one embedded static library from the host project. I'm unsure if the mixture of framework and static library is necessary, or the mixture of nested project vs in the same project.

[lilyball]

It's not just linking to the dependencies that are broken, it's also removing them from the copy files build phase.

[lilyball]

Looking at my real project, the issue also affects unit test targets that embed the nested framework.

[lilyball]

I would appreciate some acknowledgement of this issue. It's a complete blocker for adoption of CocoaPods 1.6 for us and I would have to assume other people are running into this same issue.

[dnkoutso]

Hey there sorry for the delayed response. I will be checking this out for 1.6.2 perhaps. Going over most of GH issues.

[lilyball]

@dnkoutso 1.7.0.rc.1 was published today, and there's still been no movement on this issue. This is rather concerning as I'm sure we're not the only people running into this problem.

[dnkoutso]

We can still fix this for 1.6.2 or even 1.7.0.rc.2. I haven't had the time to debug this and its most certainly related to the build settings re-write that occurred in 1.6.x.

I'd appreciate any help here for anyone to jump in and diagnose this.

[dnkoutso]

@lilyball I took a quick look... I am not sure why is there an expectation that PMHTTP and PMJSON should be available in target 'DepTest'. They are not represented in your Podfile as such.

The reason why mylib _is_ due to the fact that it is a static library from your project 'DepTest' target has a dependency to it, therefore all pods mylib must be linked to DepTest compared to DepTestKit which is a dynamic framework.

I can see why this appears to be a regression but I can also see that this is actually improved.

[dnkoutso]

Hm actually I do see a problem with removing mylib from the target dependencies list...

[dnkoutso]

I found the bug and fix.

[dnkoutso]

Determining if we should do 1.6.2 or push it to 1.7.0 its a fairly bad regression

[dnkoutso]

Fix out for 1.6.2.

[dnkoutso]

@lilyball I'd appreciate if you can just manually apply the fix to verify it works. Although I did for your own project and I was able to successfully compile.

[lilyball]

Thanks! I'll check when I have the time, but unfortunately I don't think I will today, so you shouldn't hold up the release on my testing. I assume you already tested against my DepTest sample.

[dnkoutso]

I assume you already tested against my DepTest sample.

yes and it builds.

[dnkoutso]

Released 1.6.2

[jshier]

With the mention of autocomplete breakage, I'd hoped this would fix #8716. It doesn't but it may have improved the situation a bit. Or perhaps the updates to bring xcodeproj's settings up to date helped.