[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!
- Haiku activity report - May 2020
- GSoC 2020 Project Update: XFS
- GSoC 2020 Project: Improving and Extending Services Kit
- Progress report of community bonding period
- GSoC 2020 Project: Adding XFS file system in Haiku
- GSoC 2020 Project: Input Preferences
- GSoC 2020 Project: Adding UFS2 file system in Haiku
- Haiku activity report - April 2020
- Haiku activity report - February and March 2020
- Haiku field trip report - January 2020