Swift static libraries in Beta 4?

Someone pointed this out on twitter over the weekend (from the XCb4 notes, page 7):

"The new build system supports static library targets which contain Swift code. Debugging applications which use Swift static libraries may require having a complete set of build artifacts (in their original location) available. (33297067)"


WOW!


So how can I find out more? I didn't think we had ABI compatibility now - and there was no date for it?


Does this mean the library is tied to a Xcode version? A Swift Version?


What does "complete set of build artifacts" mean?


Inquiring minds want to know!!!



Accepted Reply

I didn't think we had ABI compatibility now …

Correct.

… and there was no date for it?

Also correct.

Does this mean the library is tied to a Xcode version?

Yes.

A Swift Version?

And yes.

I believe the goal here is to allow folks with bigs apps to build their app chunkwise. The lack of binary ABI compatibility means that you can’t distribute a static library like you can, say, for C.

What does "complete set of build artifacts" mean?

It means that you have to preserve the entire contents of you build products directory (probably the entire directory inside

DerivedData
, but I haven’t looked at this in depth).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

I didn't think we had ABI compatibility now …

Correct.

… and there was no date for it?

Also correct.

Does this mean the library is tied to a Xcode version?

Yes.

A Swift Version?

And yes.

I believe the goal here is to allow folks with bigs apps to build their app chunkwise. The lack of binary ABI compatibility means that you can’t distribute a static library like you can, say, for C.

What does "complete set of build artifacts" mean?

It means that you have to preserve the entire contents of you build products directory (probably the entire directory inside

DerivedData
, but I haven’t looked at this in depth).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

I have successfully made two static libraries in beta 4, and then using them in the application without any problem. In fact it works really well, and improves the build speed and the overall structure of the application.


The problems starts when I want to distribute them in binary form and use them in the application as a library without using the static library projects inside the application project . Xcode does not recognize them, and I have tried a myriad of different things with no avail. The only error message I get is the infamous "No such module".


I read your statement that it might demand the whole substructure in DerivedData generated by the compiler, so will experiment with that as well.


Any other hints?

Now tried to incorporate the complete folders created in DerivedData for each library, and adding the .a file inside the DerivedData folders for each project into the application project build phase. Also tried out to add different paths to the "Framework Search Paths".


What files exactly does the compiler need to see from these DerivedData folders to make it recognize the library as a module?

I have successfully made two static libraries in beta 4, and then using them in the application without any problem.

Cool.

The problems starts when I want to distribute them in binary form …

I don’t think you’ll be able to make that work during the Swift 4 lifecycle. Note that the release notes mention “a complete set of build artifacts” in the context of debugging, not as a mechanism for static library distribution.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Ok,


fair enough. I will experiment some more to see if I can package stuff to somehow trick the compiler/linker to ignore that the source code is not there, and avoid any recompilation 🙂. Its used in internal distribution for the moment anyway, but i want to drive the development without

access to the source code.


Thanks.