You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following Podfile configuration files badly. It appears that it could be due to the CocoaPod having a binary instead of source code though it still head headers. Perhaps Rome could adjust the process of assembling the framework if the binary is pre-prepared.
But to make this is more difficult problem to solve, the pre-compiled may be static so it cannot simply be added to the framework folder as-is. The binary which is placed in the output framework folder called Mapbox show it is static.
> file Mapbox.framework/Mapbox
Mapbox.framework/Mapbox: Mach-O universal binary with 5 architectures
Mapbox.framework/Mapbox (for architecture arm64): current ar archive random library
Mapbox.framework/Mapbox (for architecture armv7): current ar archive random library
Mapbox.framework/Mapbox (for architecture armv7s): current ar archive random library
Mapbox.framework/Mapbox (for architecture x86_64): current ar archive random library
Mapbox.framework/Mapbox (for architecture i386): current ar archive random library
It is showing as current ar archive random library instead of Mach-O 64-bit dynamically linked shared library which would be correct. And since Swift will not work with static libraries that is a blocker.
I've set up my own workspace with my own dynamic framework and app projects the way I want them with dependencies set up as I need them to be so I do not want CocoaPods changing that configuration. This is why I am trying to use Rome and also looked at Carthage.
My next step will be to get the source code for both Mapbox and HockeyKit and set them up with framework projects so they can compile inline as needed. Another concern is leaving iOS Simulator architectures in place when submitting the app to the App Store. This was discussed with a Carthage project last year and I do not know what the status with the App Store and Xcode 7 is now.
Since my dependencies for this project will be minimal it may be easy enough to manually assemble these framework projects manually. I will then share them to the maintainers of the Mapbox and HockeyKit pods. Perhaps they can change how they configure their podspec so both can be used as regular frameworks.
The text was updated successfully, but these errors were encountered:
The following
Podfile
configuration files badly. It appears that it could be due to the CocoaPod having a binary instead of source code though it still head headers. Perhaps Rome could adjust the process of assembling the framework if the binary is pre-prepared.But to make this is more difficult problem to solve, the pre-compiled may be static so it cannot simply be added to the framework folder as-is. The binary which is placed in the output framework folder called
Mapbox
show it is static.> file Mapbox.framework/Mapbox Mapbox.framework/Mapbox: Mach-O universal binary with 5 architectures Mapbox.framework/Mapbox (for architecture arm64): current ar archive random library Mapbox.framework/Mapbox (for architecture armv7): current ar archive random library Mapbox.framework/Mapbox (for architecture armv7s): current ar archive random library Mapbox.framework/Mapbox (for architecture x86_64): current ar archive random library Mapbox.framework/Mapbox (for architecture i386): current ar archive random library
It is showing as
current ar archive random library
instead ofMach-O 64-bit dynamically linked shared library
which would be correct. And since Swift will not work with static libraries that is a blocker.I've set up my own workspace with my own dynamic framework and app projects the way I want them with dependencies set up as I need them to be so I do not want CocoaPods changing that configuration. This is why I am trying to use Rome and also looked at Carthage.
My next step will be to get the source code for both Mapbox and HockeyKit and set them up with framework projects so they can compile inline as needed. Another concern is leaving iOS Simulator architectures in place when submitting the app to the App Store. This was discussed with a Carthage project last year and I do not know what the status with the App Store and Xcode 7 is now.
Carthage/Carthage#188
Since my dependencies for this project will be minimal it may be easy enough to manually assemble these framework projects manually. I will then share them to the maintainers of the Mapbox and HockeyKit pods. Perhaps they can change how they configure their podspec so both can be used as regular frameworks.
The text was updated successfully, but these errors were encountered: