Swift on Android: sponsorship offer for bug fixes

Hi everyone,

I am aware that there is already a great thread from @drodriguez about a call for the community, but it is over a year old and recently has drifted into discussions about compiling Swift code down to the JVM. Those discussions are interesting but have a different focus to what I want to raise here. I'd like to really focus on getting the existing 90% implementation and CI work to 100%.

I am very impressed by the great coordinated effort by @Max_Desiatov and the rest of the SwiftWASM team to get that target working 100%, as well as by the possibilities they set up for others to sponsor their work (as an aside, we plan to sign up as high-level sponsors of that project in the coming days / weeks!).

With that in mind, I was curious to hear if there are other devs out there interested in working on fixing some of the few outstanding issues that appear to exist with the Swift for Android toolchains, as a coordinated effort with some sponsorship.

It seems to me that the main issues outstanding are some hard-to-track-down bugs in libdispatch (from what I understand, because its development no longer focusses on 32bit targets), and some backwards compatibility issues with libFoundation(Networking) โ€“ Android 5 + 6 do not have getaddrinfo for example, so linking fails on those platforms even if you're not interested in those APIs and everything else would work fine.

For these cases we'd be happy to integrate with the Swift JIRA in a sort of bug bounty system (if anyone knows a good bug bounty tool that integrates with JIRA we'd be very happy to hear about it).

We'd also be open to sponsor ongoing maintenance work of keeping the Android CI builds green. For that though, I think it'd be a prerequisite to discuss about unifying the various efforts that exist to build the toolchains (and stdlib etc) for Android and trying to get these into an official / standard CI process if at all possible.

I would like to mention that I am a maintainer of the SwiftAndroid ยท GitHub organisation, which could be used for this purpose. At the moment the only part of that which I'm involved in maintaining is our SwiftJNI library which we use in production (see the devel branch). It seems like some others are maintaining a libicu fork on there. The rest looks like it has not been touched since 2016 and could be archived.

I noticed that @compnerd wrote the following over a year ago in the other thread. Is there still scope for these discussions and for the creation of documentation? Have some of them happened already? I feel like this is something I could contribute towards, more so than fixing compiler bugs.

We will create a separate thread to discuss the expectations and create a living document of the expectations of both the port as well as contributors of the project towards the ports in the tree. This would cover the items of building, testing (CI), and general maintenance of the ports.

@compnerd @drodriguez @Finagolfin @v.gorlov @Gonzalo_Larralde @AndrewSB

4 Likes

Hey, it would be good to have more coordination on the Android port. Right now, @drodriguez keeps the community Android CI green, and I have been submitting pulls to get more of the toolchain working for Android, particularly with the official build-script. I'm not aware of anyone else contributing to the Android port lately.

the main issues outstanding are some hard-to-track-down bugs in libdispatch... and some backwards compatibility issues with libFoundation(Networking) โ€“ Android 5 + 6 do not have getaddrinfo for example

I have not run into those issues as I don't use those legacy platforms, nor do I know who'd be capable and interested in fixing them. Maybe your bounty will bring someone.

I think it'd be a prerequisite to discuss about unifying the various efforts that exist to build the toolchains (and stdlib etc) for Android and trying to get these into an official / standard CI process if at all possible.

Yes, that would be good. I currently provide Swift 5.3 SDKs for Android, which include the corelibs like Foundation and XCTest, and have been planning to set up a CI on github actions with it, that cross-compiles various Swift packages like NIO or swift-crypto and runs their tests in an Android emulator daily. The current community CI only cross-compiles the Swift stdlib and runs the 90% of the compiler test suite that can be run from a linux host when cross-compiling, ie no executable tests that need to run on Android, after every merged commit in the main branch.

We could probably use the Android emulator and have it run the executable tests too, and once my linked pull above is in, have it cross-compile the corelibs on every merged commit too, catching regressions sooner.

The Android port is a shoestring operation at the moment, help is welcome.

Is there still scope for these discussions and for the creation of documentation?

No idea, may have stalled, as Saleem seems busy with the Windows port.

2 Likes