Cocoapods: Simulator as a distinct platform?

[stephencelis]

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

---

I've looked through the guides and there doesn't seem to be a way of specifying simulators as platforms (_e.g._, https://guides.cocoapods.org/syntax/podspec.html#group_multi_platform_support).

A pod I maintain, SQLite.swift, requires a bit of a kludgy setup to get working with CocoaPods (hacks that I am able to avoid with either a regular sub-project or Carthage). Other pods requiring similar setups suffer from similar problems. (See https://github.com/CocoaPods/CocoaPods/issues/3942 for a potential solution that avoids the hack.)

My current (now broken) hack uses a custom module map to point to the SDK sqlite3.h header. Previous versions of Xcode allowed us to point to any SDK header for any SDK build, but the 7.3 release has gotten more strict, only allowing headers within the current SDK root.

Short of solving the issue _via_ #3942, could CocoaPods allow some kind of ability to override build settings with a simulator namespace? _E.g._:

  spec.osx.module_map = 'path/to/osx/module.modulemap'
  spec.ios.module_map = 'path/to/ios/module.modulemap'
  spec.ios.simulator.module_map = 'path/to/ios/simulator/module.modulemap'
  # …

(/cc @groue)

[mRs-]

I have a similar problem with sqlite3 more information about this here: https://github.com/CocoaPods/CocoaPods/issues/5072#issuecomment-200229519

[segiddins]

This seems... Complicated. I think, at least for sqlite, the best approach might be to create a Pod that has a modulemap. Do module maps not have a way to reference the current target SDK at all?

[groue]

@segiddins: Unfortunately, modulemaps can only contain absolute paths, and do not support variables like SDK_ROOT or alike.

In order to avoid this issue, GRDB.swift, another SQLite CocoaPod, uses a single module map that defines ad-hoc modules, one for each platform:

Pod::Spec.new do |s|
  ...
  s.module_map = 'Support/module.modulemap'
end

The modulemap it self is:

framework module GRDB {
    umbrella header "GRDB.h"

    export *
    module * { export * }
}

module SQLiteMacOSX {
    header "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/sqlite3.h"
    export *
}

module SQLiteiPhoneOS {
    header "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/sqlite3.h"
    export *
}

module SQLiteiPhoneSimulator {
    header "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include/sqlite3.h"
    export *
}

The problem is that the source code itself now has to import the correct module, depending on the platform:

#if os(OSX)
    import SQLiteMacOSX
#elseif os(iOS)
    #if (arch(i386) || arch(x86_64))
        import SQLiteiPhoneSimulator
    #else
        import SQLiteiPhoneOS
    #endif
#endif

Oh, and all of this makes iOS7 support quite difficult.

In one way or another, supporting CocoaPods is difficult.

[segiddins]

:/ Well that kinda sucks. If we receive a proposal for how this simulator platform would work that isn't too much of a disturbance to the rest of the codebase, it might be something we could accept a PR for!

[jancassio]

Hello,

I'm in the same trouble. I expected something similar like @stephencelis proposal.

The @groue solution at first sight makes sense and probably will fix my issue, but for me still looking like a workaround :(

Anyway thank you for the ideas.

[mrackwitz]

One way to tackle this could be platform-specific xcconfig definitions.

spec.pod_target_xcconfig = {
     "MODULEMAP_FILE[sdk=iphonesimulator*]" => "path/to/ios/simulator/module.modulemap"
}

The remaining issue with that is that we define pod target xcconfigs in the xcconfigs, but override the MODULEMAP_FILE with a custom value in the stored build settings of the pod target within the Pods.xcodeproj for the path of the custom or generated modulemap. We could add checks for such conflicting build settings and resolve it by giving precedence to the settings defined in pod_target_xcconfig.

[keith]

Another issue with this might be the path to the module map. I attempted that solution but had issues for development pods vs normal pods.

Keith Smiley

On May 11, 2016, at 02:57, Marius Rackwitz [email protected] wrote:

One way to tackle this could be platform-specific xcconfig definitions.

spec.pod_target_xcconfig = {
"MODULEMAP_FILE[sdk=iphonesimulator*]" => "path/to/ios/simulator/module.modulemap"
}
The remaining issue with that is that we define pod target xcconfigs in the xcconfigs, but override the MODULEMAP_FILE with a custom value in the stored build settings of the pod target within the Pods.xcodeproj for the path of the custom or generated modulemap. We could add checks for such conflicting build settings and resolve it by giving precedence to the settings defined in pod_target_xcconfig.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[stephencelis]

For reference, our current solution to the problem is:

  s.pod_target_xcconfig = {
    'SWIFT_INCLUDE_PATHS[sdk=macosx*]'           => '$(SRCROOT)/path/to/macosx',
    'SWIFT_INCLUDE_PATHS[sdk=iphoneos*]'         => '$(SRCROOT)/path/to/iphoneos',
    'SWIFT_INCLUDE_PATHS[sdk=iphonesimulator*]'  => '$(SRCROOT)/path/to/iphonesimulator',
    'SWIFT_INCLUDE_PATHS[sdk=appletvos*]'        => '$(SRCROOT)/path/to/appletvos',
    'SWIFT_INCLUDE_PATHS[sdk=appletvsimulator*]' => '$(SRCROOT)/path/to/appletvsimulator',
    'SWIFT_INCLUDE_PATHS[sdk=watchos*]'          => '$(SRCROOT)/path/to/watchos',
    'SWIFT_INCLUDE_PATHS[sdk=watchsimulator*]'   => '$(SRCROOT)/path/to/watchsimulator'
  }

Each directory has a module map that points to the "C" lib module map, which gets imported by the pod. _E.g._, for Apple TV:

module CSQLite [system] {
    header "/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS.sdk/usr/include/sqlite3.h"
    export *
}

[keith]

I guess my problem with that was I was trying not to hard code custom paths for the module maps.

[stephencelis]

@keith Same. #3942 would be the only solution that avoids module map hacks and generation.

[tconkling]

Just chiming in here: I have a machine learning framework, written in Swift, that makes heavy use of Metal and MetalPerformanceShaders. I'd love to publish this as a Cocoapod, but am unable because Metal isn't available on the simulator.

(No amount of conditional compilation, short of stubbing out every class, will let this framework run on the simulator, since Metal is central to everything it does.)

Being able to opt out of compiling for the simulator would solve the problem. I understand the project isn't keen on allowing people to restrict architectures (per https://github.com/CocoaPods/CocoaPods/issues/5472), but there's no other option for Metal users unless and until Apple supports Metal on the simulator.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem :+1: