Swift for the content creation industry, metaverse, and beyond

Community Showcase
, , , ,
1

I would like to begin by saying thank you to the entire swift team for the incredible work done to make cxx-interop possible. I think this this will play into a pivotal moment for swift in its ability to write cross-platform applications, especially for computer graphics applications designed for content creation and the visual effects industry (given the prominence of C++ across its software landscape).

Universal Scene Description (USD) for Swift
Universal Scene Description (USD) for Swift1920×1272 240 KB

Through cxx-interop and the tooling of SwiftPM, I've so far been able to build many of the industry's C++ libraries without a single line of CMake in MetaverseKit, and then additionally provide these libraries as package dependencies through SwiftPM to bring Pixar's Universal Scene Description (USD) to the swift programming language with SwiftUSD.

I'm very curious to the rest of the community's thoughts here, what has your development experience been like with swift's cxx-interop so far? What are your thoughts on its potential with interoperability with other languages in the future like Rust? And more generally, how do you think the existing C/C++ landscape might benefit from Swift's tooling here?

Thank you all!! :heart:

6 Likes
2

Nice, I have no interest in the "Metaverse" but I took a look at your MetaverseKit wrapper package and there are some libraries I am interested in using. Have you tried building for Android at all using my Android SDK, as Android headsets currently dominate? Unfortunately, C++ Interop has never worked fully on the Android port, so you would've likely seen issues.

Let me ask you in return: what has your development experience with Swift been like?

2 Likes
3

Have you tried building for Android at all using my Android SDK, as Android headsets currently dominate?

Your effort so far on putting that together for Android is incredible! I have not attempted anything on Android as of yet, but it's planned for the backlog. It looks like your work on that will pave the way into bringing all of this over to Android, I'm excited to try it out. I have ensured to maintain full support on Linux, though I've been running it on Ubuntu 23.04 aarch64 (Lunar Lobster), so distros and versions will likely vary as I've just not been able to get around to testing those platforms yet.

Unfortunately, C++ Interop has never worked fully on the Android port, so you would've likely seen issues.

Have you been able to keep a record of some of these errors? I'd be happy to take a look into them and attempt to figure out some solutions.

Let me ask you in return: what has your development experience with Swift been like?

My development experience with Swift has honestly been great, especially with cxx-interop!

However, I should warn you ahead of time that I've been rather quick to just chaotically restructure a huge cxx project for the sake of adhering to the very strict requirements of SwiftPM's little to zero flexibility in how it expects each target's public header directories to exist within respect to each other -- so it's a lot of shameless modification on my end of current cxx projects into this typical directory structure:

  • sources:
    Sources/MyCxxTarget/MyCxxTarget.cpp
  • header files:
    Sources/MyCxxTarget/include/MyCxxTarget/MyCxxTarget.h

The (extremely unfortunate) limitation of having very little control of how to specify include directories for targets via the publicHeadersPath property is the reason this massive restructuring of existing projects is necessary, and is currently a show-stopper in terms of official projects (such as Pixar with USD) from being able to officially adopt Swift & SwiftPM given this limitation.

Aside from that critical limitation, I've honestly experienced very little issues, there are some annoying things I've experienced such as very slow compilation times (but I'm also building a bit of a ridiculous amount of libraries together at once for USD's sake), so that bit is expected, and sourcekit seems to be really struggling at times with cxx interop which I am hoping will improve here soon, and other just very minor things.

Overall the experience has been amazing, but I can't wait until we get more flexibility in the include directory dilemma outlined above.

4

Yep, detailed logs from the compiler validation suite, including this recurring error:

Command Output (stderr):
--
<unknown>:0: warning: the '-enable-experimental-cxx-interop' flag is deprecated; please pass '-cxx-interoperability-mode=' instead
<unknown>:0: note: Swift will maintain source compatibility for imported APIs based on the selected compatibility mode, so updating the Swift compiler will not change how APIs are imported
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "SwiftGlibc.h"
         ^
/data/data/com.termux/files/home/build/Ninja-Release/swift-android-aarch64/lib/swift/android/aarch64/SwiftGlibc.h:165:10: note: in file included from /data/data/com.termux/files/home/build/Ninja-Release/swift-android-aarch64/lib/swift/android/aarch64/SwiftGlibc.h:165:
#include <iconv.h>
         ^
/data/data/com.termux/files/usr/include/iconv.h:122:3: error: missing '#include <bits/mbstate_t.h>'; 'mbstate_t' must be declared before it is used
  mbstate_t dummy2;
  ^
/data/data/com.termux/files/usr/include/bits/mbstate_t.h:47:3: note: declaration here is not visible
} mbstate_t;
  ^
<unknown>:0: error: could not build C module 'SwiftGlibc'

I will be trying some things in the coming weeks and let you know how that goes. If my attempts don't work, I may take you up on that. :wink:

5

Would you be able to show me what the SwiftGlibc.h umbrella header looks like?

#ifndef __SWIFT_GLIBC_H__
#define __SWIFT_GLIBC_H__

// in file SwiftGlibc.h

// ...

#include <iconv.h>

// ...

#endif /* __SWIFT_GLIBC_H__ */
6

It looks exactly the same as it does in the linux toolchain, as both use that same header, which has not been modified in years. However, there are efforts underway to properly modularize that C library for Swift, so I'm hoping that will get C++ Interop working fully for the first time with the Android port.

7

I was just curious what the actual raw generated umbrella header looks like as I have never seen it before, example.

But yes, modularizing that library makes a lot of sense, afaik the existing approach was never intended to be all-encompassing of that C library, where even just the absence of a couple header includes could quickly progress into the chaos you ran into in your error above.

Being modularized can ensure every include is provided for, and at least if you run into any problems - they are scoped to just a couple offending modules instead of having the entire library to worry about.

8

If you download a Swift toolchain for linux and look at usr/lib/swift/linux/x86_64/SwiftGlibc.h, the one for Android is identical to that, modulo comments. You can check that for yourself by downloading my Android SDK linked above and diffing the two.

1 Like
9

@Finagolfin I gotta trivia question for you because I'm clueless.