Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Vendored framework inside of pod not recognized by project or other pods (Cocoapods/Cocoapods #3810)

In my project, I reference several private pods that my company uses. One of these pods called DKKit is dependent on another private pod that I've included called BaseProKit. BaseProKit contains 3 frameworks that it references inside of its header and implementation files, which I believe are considered vendored_frameworks. In the existing header files of BaseProKit, there are references to these frameworks via imports like #import <PPCommon/PPCommon> which work just fine (usually) when compiling while solely relying on the BaseProKit pod. However, when DKKit is included, there is a header alias that DKKit looks for when importing (BaseProKit.h) which contains the above import. However, in the context of DKKit, it would seem that the DKKit pod is unaware of the existence of the PPCommon framework, and it only sees its header files' aliases referenced via Pods-BaseProKit. Because of this, any and all references to <PPCommon/ANYTHING> create compilation errors (not found), and the only way I've been able to figure out so far is that just referencing via #import "PPCommon.h" which would require me to adjust all of the imports in the entire BaseProKit project, and that doesn't feel right.

I have included the following files for reference: The Podspec for BaseProKit:

  s.name         = "BaseProKit"
  s.version      = "1.0.5"
  s.source_files = "BaseProKit/BaseProKit.h",
                   "BaseProKit/Data/*.{h,m}",
                   "BaseProKit/Sensor Calibration/*.{h,m}",
                   "BaseProKit/SP3D/BaseballSceneController/*.{h,m}",
                   "BaseProKit/SP3D/SceneElements/*.{h,m,hpp,cpp}",
                   "BaseProKit/SP3D/SceneEnvironment/*.{h,m}",
                   "BaseProKit/Third Party/DeviceModelDetector.{h,m}",
                   "BaseProKit/Third Party/SkyProKitEmptyMMFile.{h,mm}"
  s.resources = "BaseProKit/SatelliteLibrary/SatelliteLibrary.bundle","BaseProKit/SP3D/SP3DResources.bundle", "BaseProKit/SP3D/Models/Vertex Data/*"
  s.frameworks = "GLKit", "OpenGLES", "Foundation", "UIKit", "Accelerate", "PPCommon", "SatelliteLibrary", "SP3D"
  s.library = 'c++'
  s.prefix_header_file = "BaseProKit/BaseProKit-Prefix.pch"
  # s.public_header_files = "BaseProKit/PPCommon/PPCommon.framework/Headers/*.h", "BaseProKit/SatelliteLibrary/SatelliteLibrary.framework/Headers/*.h", "BaseProKit/SP3D/SP3D.framework/Headers/*.h"

  s.vendored_frameworks = "BaseProKit/PPCommon/PPCommon.framework",
                          "BaseProKit/SatelliteLibrary/SatelliteLibrary.framework",
                          "BaseProKit/SP3D/SP3D.framework"

The Podspec for DKKit:

    s.name          = "DKKit"
    s.version       = "1.0.0"

    s.source_files  = 'DKKit/**/*.{h,m}'
    s.resources = 'DKKit/**/*.xcdatamodeld'
    s.dependency 'PromiseKit/Promise', '~> 1.3.0'
    s.dependency 'MBProgressHUD', '~> 0.9.1'
    s.prefix_header_contents = '#import "NSDictionary+Merge.h"'
    s.frameworks = 'CoreData'

    s.dependency 'BaseProKit', '~> 1.0.5'
    s.dependency 'SwingAnalysisKit', '~> 1.0.0'

My project's Podfile:

pod 'SwingAnalysisKit', :git => "https://swing-analysis-kit-URL", :branch => "develop"
pod 'BaseProKit', :git => "https://base-pro-kit-URL", :branch => "develop"
pod 'DKKit', :git => "https://DKKit-URL", :branch => "develop"

Is there anything I could be doing differently in either of my podspec files (particularly the one for BaseProKit) to assure that these frameworks can be references as frameworks (rather than just their header files) outside of the Pod itself?

Copying this to the Cocoapods/Cocoapods repository as an issue as well: https://github.com/CocoaPods/CocoaPods/issues/3810

like image 903
Jim Cervone Avatar asked Nov 09 '22 09:11

Jim Cervone


1 Answers

There are a number of issues raised on the CocoaPods repo related to this - e.g., 1824, 3161. I believe it has been fixed in 0.38.0.beta.1 -

Added recursive support to the public headers of vendored frameworks that are automatically linked in the sandbox. This fixes and issue for framework header directories that contain sub-directories. Todd Casey #3161

Public headers of vendored frameworks are now automatically linked in the sandbox. That allows transitive inclusion of headers from other pods. Vincent Isambart #3161

Source: Changelog

like image 71
johnpatrickmorgan Avatar answered Dec 09 '22 09:12

johnpatrickmorgan