Any way to create a module without creating a new Xcode target?
10 views
Skip to first unread message
Jens Alfke
May 15, 2015, 2:29:14 PM5/15/15
to swift-l...@googlegroups.com
I need to write unit tests for some code of mine that accesses Obj-C runtime metadata. It appears that my code has trouble with the metadata (or it’s simply missing) when it involves a Swift class declared in a module
The problem is that to test this I need a class in a module, and from looking at the docs, the only way to do that is to create a new Xcode framework target, with all the rigamarole that entails. (Actually I’d need two, one for iOS and one for Mac.) Is there any other way to do this? Like a “module Foo” statement, similar to every single other existing language that supports modules?
—Jens
The problem is that to test this I need a class in a module, and from looking at the docs, the only way to do that is to create a new Xcode framework target, with all the rigamarole that entails. (Actually I’d need two, one for iOS and one for Mac.) Is there any other way to do this? Like a “module Foo” statement, similar to every single other existing language that supports modules?
—Jens
Adam Sharp
May 19, 2015, 10:58:12 PM5/19/15
to swift-l...@googlegroups.com
On 16 May 2015, at 4:29 am, Jens Alfke <je...@mooseyard.com> wrote:
> The problem is that to test this I need a class in a module, and from looking at the docs, the only way to do that is to create a new Xcode framework target, with all the rigamarole that entails. (Actually I’d need two, one for iOS and one for Mac.) Is there any other way to do this? Like a “module Foo” statement, similar to every single other existing language that supports modules?
I don't think there's anything language-level like that. The way I've done it is to use swiftc to build a dynamic library, e.g.:
> The problem is that to test this I need a class in a module, and from looking at the docs, the only way to do that is to create a new Xcode framework target, with all the rigamarole that entails. (Actually I’d need two, one for iOS and one for Mac.) Is there any other way to do this? Like a “module Foo” statement, similar to every single other existing language that supports modules?
$ swiftc -emit-library -o build/libFoo.dylib -module-name Foo Foo/*.swift
$ swiftc -emit-module -o build/Foo.swiftmodule -module-name Foo Foo/*.swift
$ swiftc -Lbuild -Ibuild -lFoo main.swift
Managing the linker search paths, linked libraries and import search paths like this kinda sucks, and frameworks do abstract away some of that for you. But the tradeoff is that building the framework bundle itself is a bit more complicated. It's definitely doable though, and easier once you write a build script or something to automate it.
It would be nice if there was a simpler way, but I think tooling can definitely solve the problem.
–Adam
Jens Alfke
May 19, 2015, 11:03:39 PM5/19/15
to Adam Sharp, swift-l...@googlegroups.com
On May 17, 2015, at 3:30 AM, Adam Sharp <ads...@me.com> wrote:It would be nice if there was a simpler way, but I think tooling can definitely solve the problem.
I don’t think it solves everything. I don’t want the overhead of multiple dylibs (losing link-level optimization, incurring load-time costs, losing iOS 7 support, etc.) just to have modular code.
—Jens
Reply all
Reply to author
Forward
0 new messages