[GSoC 2017] Porting Swift to Haiku - Final Report
This blog-post marks the final report on bringing Swift to Haiku in the Google Summer of Code period. My introductory post on this project can be found here for a brief overview of the project.
In the last 3 coding periods, my contributions to Haiku’s LLVM and Clang ports plus reporting some bugs with the Haiku developers have made it possible for the Swift toolchain to be built on Haiku. With this, it opens the possibility to use cross-platform Swift libraries used on other platforms and also allows to directly use the libc/glibc libraries via the GlibC module. I have already done an initial port of Foundation and libdispatch on Haiku as specified in the previous blog-post, but they still need to be polished for general use. As for upstreaming my patches for Haiku support, I’ve sent my patches to apple/swift and they are currently under review.
What has been completed:
- Building Swift 3.1 and Swift 4 on Haiku:
- Added support for x86_64-unknown-haiku.
- Built swiftc and its standard library via patching the build-script.
- Updated and upstreamed LLVM port to build upstream swift.
- Executing simple Swift programs (compiled or interpreted).
- Initial port of Foundation and libdispatch.
- Swift 3.1 recipe is available at HaikuPorts.
- Run tests against the newly built standard library and swiftc.
- Sent pull request upstream to apple/swift (PR #11583)
What needs to be done (After GSoC):
- Package Manager support via llbuild.
- Debugging Swift via porting LLDB.
- Building SourceKit for Haiku.
- Update the Swift 3 recipe to Swift 4.
- More testing support.
- (1) Add Initial platform support for Haiku.
- (2) swift-lang: WIP new recipe.
- (3) Define OS Check for Haiku.
- (4) unistd.h: define _POSIX_BARRIERS.
- (5) libedit: enable wide-character support.
- (6) clang: Enable thread-local storage in clang.
- (7) libexecinfo: fix symlink paths.
There were some difficulties encountered when working with platform-specific APIs. For instance, whilst I was porting the CoreFoundation and libdispatch libraries, many functions such as kqueue(), epoll() and ppoll() were unavailable on Haiku and I had to stub out any code containing them.
One other difficulty I had to deal with was keeping my branches synced with upstream, so that my changes can be merged cleanly without any conflicts. The importance of regularly rebasing your work always helps when planning to support a new OS platform; which reduces the maintenance effort and to some extent, won’t be easily susceptible to ‘bitrot’. This was one of the methods that helped me cleanly upstream my GSoC work.
Achievements and Thanks:
I’ve gained a lot of knowledge in understanding the internals of Haiku’s POSIX layer and implementing missing features found in 3rd-party software requiring OS-specific code. With this experience, contributing to Haiku during the GSoC period has increased my confidence in submitting better patches to other projects and more importantly to the Haiku sources. I will still continue to contribute to porting more essential open-source software to the platform and will also get more familiar with the lower-level side of Haiku (the kernel, device drivers and porting to more embedded platforms) if time permits.
I would really like to thank my mentors jua and korli and all of the Haiku developers in helping me overcome the obstacles in my project and making this possible to complete. Thank you for reading this blogpost, it has been great to be part of Haiku in GSoC 2017!
- [GSoC 2018 - TrackGit] Progress Report 11
- [GSoC 2018: SDHCI MMC Driver]: Third Phase Outline
- [GSoC 2018: SDHCI MMC Driver]: Week #8
- [GSoC 2018 - TrackGit] Progress Report 10
- LibreOffice for Haiku, a not-so-short story
- The State of Rust on Haiku - July 2018
- [GSoC 2018: SDHCI MMC Driver]: Week #7
- [GSoC 2018: XFS support] Week #7 and #8
- Haiku monthly activity report - 06/2018
- [GSoC 2018 - TrackGit] Progress Report 9