Just wanted to give you an update: I was able to declare a stub package for the Apple System Log's C headers and expose them to Swift. I'm happy to report that I'm now able to compile against asl.h successfully and can call the API from Swift.
The package declaration for ASL is here -- perhaps other people might find it helpful:
As you'll notice in the module map, I'm hard-coding the path to a specific version of the Mac OS X SDK:
That's definitely not great in the long-run; do you know if there's a better way to do it?
Not yet, we still need a design for this.
I would love to help push this tool forward; I was wondering if you or anyone else at Apple could shed some light on what might be in active development with SPM and where you're looking for community involvement?
Our current proposals are a good indication of what Max and I are working on (Tests and C source integration, respectively).
Currently we could use help with screening and triaging the bugs in the Package Manager component on bugs.swift.org, and then trying to either get fixes for them (if they are just bugs), or trying to sort out what the overarching problems are and how to address them.
In particular I'd be interested in looking at adding iOS, tvOS and watchOS support, as I've noticed there doesn't seem to be a way to specify a platform other than OS X, which is built by default.
Are you talking about apps for those platforms, or just being able to build libraries targeting them that could then be integrated into apps?
Tackling full on apps is a big project because of all the other pieces that are necessary (support for resources, support for real frameworks, support for different product types, etc.). Tackling just being able to build libraries targeting those platforms should be more tractable though. There are a varies things we will need for that. In no particular order:
1. A design for the command line workflow for specify the deployment platform.
2. An implementation of the internal platform specific configuration "stuff" (i.e., how are we going to organize platform specific code in swiftpm itself).
3. A design for how we would add platform specific attributes for targets. There is a straw man included in the Swift based manifest proposal (https://github.com/apple/swift-package-manager/blob/master/Documentation/Internals/SwiftBasedManifestFormat.md) for declaring conditional dependencies. I'm not sure how quickly we would need this to do useful things.
If you are interested in the app side, then it will be a long road, but the best place to start is tackle an individual feature (like support for resources) and come up with a design that integrates and works with what is already there.
On Dec 14, 2015, at 10:45 PM, Evan Maloney <firstname.lastname@example.org> wrote:
On Dec 14, 2015, at 11:37 AM, Evan Maloney <email@example.com> wrote:
Thanks for the tip, Daniel. I'll give that a try.
Very excited that SPM was included in the Swift release. It's going to solve a real pain point for developers.
On Dec 14, 2015, at 11:28 AM, Daniel Dunbar <firstname.lastname@example.org> wrote:
On Dec 14, 2015, at 8:15 AM, Evan Maloney via swift-build-dev <email@example.com> wrote:
I have a project that has a dependency on the asl.h system header.
This header is present on all Apple platforms. When building with Xcode, this dependency is specified in the bridging header, allowing the C API provided by asl.h to be exposed to Swift.
For now, the only way to do this is with the "system modules" feature (and a hard coded path): https://github.com/apple/swift-package-manager/blob/master/Documentation/SystemModules.md
As far as I can tell, there's no way to specify a bridging header using the Swift Package Manager or to otherwise specify a C API to expose to Swift.
Am I mistaken? Am I just missing something? Or is SPM only intended to be used to build something in "pure Swift"?
You are correct, but it isn't about "intention", this is just stuff which isn't supported *yet*.
swift-build-dev mailing list