Cocoapods: 1.6.0.beta.1 regression: nested target leads to 'dyld: Library not loaded'

[ZevEisenberg]

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

Report

What did you do?

1. I'm using macOS, but this also happens on iOS.
2. Integrate CocoaPods 1.5.3.
3. Create an app and a Utilities framework. I called the app "Pather" in my sample code because I though the issue was runpath-related.
4. In the Podfile, nest the app target inside the Utilities target.
5. Add a dependency to the "outer" target. I'm using a fork of the SwiftGraph library. Not sure if the particular library is relevant, but this bug does not reproduce if no dependencies are declared in the Podfile. Use the dependency in the Utilities framework, and call into Utilities from the main framework.
6. Confirm that the app runs successfully.
7. Update to CocoaPods 1.6.0.beta.1.

What did you expect to happen?

The app continues to run successfully.

What happened instead?

Error when the app tries to run:

dyld: Library not loaded: @rpath/SwiftGraph.framework/Versions/A/SwiftGraph Referenced from: /Users/zeisenberg/Library/Developer/Xcode/DerivedData/Pather-apyisjedacufuxbmjgfvcjuwgkwk/Build/Products/Debug/Pather.app/Contents/MacOS/Pather Reason: image not found

CocoaPods Environment

Stack

   CocoaPods : 1.6.0.beta.1
        Ruby : ruby 2.4.4p296 (2018-03-28 revision 63013) [x86_64-darwin17]
    RubyGems : 2.7.7
        Host : Mac OS X 10.13.6 (17G2208)
       Xcode : 9.4.1 (9F2000)
         Git : git version 2.18.0
Ruby lib dir : /Users/zeisenberg/.rvm/rubies/ruby-2.4.4/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 445478b05500b7362bb4f7796d489574e791a90e

Installation Source

Executable Path: /Users/zeisenberg/.rvm/gems/ruby-2.4.4/bin/pod

Plugins

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

Podfile

# Uncomment the next line to define a global platform for your project

target 'Utilities' do
  platform :macos, '10.13'
  use_frameworks!
  pod 'SwiftGraph', :git => "https://github.com/ZevEisenberg/SwiftGraph.git"

  target 'Pather' do
    inherit! :search_paths

  end
end

Project that demonstrates the issue

Project includes Git repository with commits that demonstrate the bug.

Pather.zip

[ZevEisenberg]

Note: I don't remember why I had the targets nested the way I do, with the main app nested inside the utilities target. I think it was to work around a bug at some point, but since I don't understand what target nesting signifies in CocoaPods, the answer here may be that I'm "holding it wrong." Still, it appears to be a regression.

[ZevEisenberg]

Confirmed that if I nest in the other direction, with Pather containing Utilities, then the app runs correctly. i.e. this Podfile works:

target 'Pather' do
  platform :macos, '10.13'
  use_frameworks!

  target 'Utilities' do
    inherit! :search_paths
    pod 'SwiftGraph', :git => "https://github.com/ZevEisenberg/SwiftGraph.git"
  end
end

[dnkoutso]

Thanks for report and sample app.

[ZevEisenberg]

Oh, and I thought it might be related to https://github.com/CocoaPods/CocoaPods/issues/7985 but not sure

[dnkoutso]

Confirmed regression, not related to #7985.

[dnkoutso]

It might actually not be a regression and we are now doing the correct thing I will need to investigate further.

[dnkoutso]

@ZevEisenberg this seems intentional

https://github.com/CocoaPods/CocoaPods/pull/7992

It appears that since your target has inherit! :search_paths it will no longer copy the targets of your framework into the App.

CocoaPods has logic to "transfer" dependencies of embedded targets (extensions, dynamic frameworks (although for these maybe it shouldnt) into the app thats hosting them.

I think your best bet is to turn the relationship around as you did.

[dnkoutso]

@ZevEisenberg with all due respect I am going to close this one. The PR has even a test case similar to yours (except it uses static library)

Alternatively you can remove the inherit! :search_paths entry and I believe should work.

[ZevEisenberg]

@dnkoutso thanks for the reply - sounds like I am indeed "holding it wrong." I'll invert the dependencies, and if that creates problems, I'll file a new bug. Is there a rule of thumb for how targets should be nested? Since CocoaPods 1.5.x didn't seem to care, but 1.6 does, what's the heuristic here?

[dnkoutso]

Generally this is more of the standard practice but it could work the other way around (removing inheritance).

I think CP1.6.0 honors this entry more correct.

[ZevEisenberg]

I guess I don’t understand what inherit! :search_paths does, since I think I’m not alone in being an iOS developer who doesn’t understand how search paths work, what they mean for CocoaPods, and why I might want to inherit them (or not). The CocoaPods docs on this just say that it allows you to control what gets inherited, without explaining the implications of that decision. Might be a nice area for some improved documentation. Also might be nice to catch it at pod install time, if there’s any way to tell that a configuration like the one I had couldn’t possibly work. But I don’t know if you can reliably determine that.

[dnkoutso]

The latter part will be difficult.

Inherit search paths basically means "from my parent targets only bring in the search paths and nothing else, like linker flags". This effectively means that the nested target will not link the dependencies of the parent because the parent will link them.

This is common for test targets where the tests are hosted by the app target and therefore there is no need to double link dependencies (otherwise you get warnings).

Now again, CocoaPods has since early days (way before I was involved) some logic to automatically link pods from targets that are meant to be embedded like extensions of frameworks to their host target which is exactly your case here but we now properly honor that setting.

Its definitely in need of better docs I agree and can be folder under https://github.com/CocoaPods/CocoaPods/issues/7579