Microsoft recently announced Bash on Ubuntu on Windows: now you can compile and run the Swift compiler on Windows 10.

Note that all compiled Swift binaries are only executable within Bash on Windows and are Ubunutu, not Windows, executables.

Make sure to run all commands from Bash, or the project won't compile.

If you have any comments, feedback or questions, tweet me @bellamy_hugh.

Setup your box

  1. Install Windows Subsystem for Linux here and restart your PC.
  2. Follow the instructions for setting up Bash on Windows.bash
  3. Install the developer dependencies needed to compile the Swift project.sudo apt-get install git cmake ninja-build clang python uuid-dev libicu-dev icu-devtools libbsd-dev libedit-dev libxml2-dev libsqlite3-dev swig libpython-dev libncurses5-dev pkg-config libblocksruntime-dev libcurl4-openssl-dev
  4. Install a version of clang with C++ 14 support - the default version of clang on WSL results in linker errors during compilation. sudo apt-get install clang-3.6
    sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-3.6 100
    sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/bin/clang++-3.6 100
  5. Install the latest version of CMake - the version of CMake on WSL is too old and cannot compile the Swift project. This may take up to 30 minutes. wget
    tar xf cmake-3.5.2.tar.gz
    cd cmake-3.5.2
    sudo make install
    sudo update-alternatives --install /usr/bin/cmake cmake /usr/local/bin/cmake 1 --force
    cmake --version # This should print 3.5.2

Get the code

  1. Open a command prompt in the directory where you want to contain the swift project.
  2. Create a directory to contain the swift project and its dependencies. This may take up to 5 minutes. mkdir swift-source
    cd swift-source
  3. Clone the Swift source code. This may take up to 15 minutes. git clone
    ./swift/utils/update-checkout --clone

Build the code

  1. Compile the Swift compiler and standard library - this takes between 30 minutes and 2 hours depending on your PC. ./swift/utils/build-script -r

Compile some Swift code!

  1. Navigate to the built Swift binaries. This may depend on your build\Ninja-RelWithDebInfoAssert\swift-linux-x86_64\bin
  2. Create a file with some Swift code. This can be done from the command line in WSL or from Explorer in Windows. vim
    print("Hello World")
    save test.swift
  3. Compile the Swift code from WSL../swiftc test.swift
  4. Run the Swift binary!./test

I've recently been an active contributor to the corefxproject on GitHub.

In this blog post, I will assess my experience of contributing to the project, and consider ways to improve how corefx and similar large Microsoft projects work as OSS.

The Good

  • GitHub issues:
  • Members of the corefx team use GitHub as an open issue tracker. This yield a variety of benefits.

    Firstly, issues can be tracked easily and directly from within PRs. Secondly, contributors can easily find areas to work on. This is vastly helped by GitHub's tagging system: I can find an issue marked up-for-grabs to find potential contributions, for example.

  • Pull Requests:
  • Across most .NET Foundation projects, including corefx, coreclr and roslyn, all contributors, including internal Microsoft employees, have to submit PRs, instead of directly submitting code. Although this decreases the number of code changes to the project, it has the following benefits.

    Firstly, it treats internal and external contributors the same way. This leads to more external contributors, and provides more transparency exposing the design decisions of Microsoft employees.

    Secondly, it improves code quality. Nits are spotted and fixed in code-review, and even external contributors can review code as well.

    Thirdly, it is accountable. PRs can be referenced, instead of individual commits, linking together commits and code decisions.

  • Continuous Integration:
  • All PRs are tested on all supported platforms on which corefx runs. When the CI is up (downtime can be high), this works like a dream, as contributors don't have to test their code on many platforms, and .NET Foundation members don't have to worry about the build breaking. This is better than other OSS such as apple/swiftthat relies on employees manually triggering CI builds, and the external contributor having to test code on both Linux and OSX.

The Bad

  • Ungrateful code merging
  • In the hustle and bustle of working at Microsoft, many of my PRs (of all sizes) are merged with only a "LGTM" once the CI passes. This can lead to a feeling of lack of recognition of the work you spent time on.

  • Lack of interaction between internal and external contributors
  • It feels as if there is a split between Microsoft and non-Microsoft employees. This can arise from employees not interacting with external contributors in terms of answering questions or using unfamiliar vocab, or the team not being transparent about the corefx roadmap.


  • Say thanks!
  • Microsoft should be grateful for external contributions. Code reviewers should not sign a review off with a "LGTM", but also a really short "thanks" and an encouragement for future contributions. Other examples include code reviewers being more polite and receptive during code-review.

  • Suggest further work
  • Employees should mark more issues as up-for-grabs, as this encourages contributions for work the Microsoft team would otherwise not be able to do. Furthermore, code reviewers could suggest areas for further research, and suggest other similar ways that contributors can contribute after the PR is merged.

  • Interact more
  • I understand that Microsoft employees are not paid to talk to random people online, but they should be more interactive with external contributors. Recently, I asked a question to an employee, and it went ignored. Try to answer more questions asked by members of the open-source community, as this encourages worthwhile discussion and contributions.

  • Acknowledge PRs
  • Again, Microsoft employees are busy, and in some circumstances, I have overloaded them with PRs. That said, it would be nice to know that some of my PRs are not forgotten. For example, a comment saying Thanks for the contribution! We'll take a look at this in X dayswould really be appreciated.


That brings me to the end of an analysis that I hope did not come across too ranty. Corefx is a great project, and is very well managed. However, the business of being employed by Microsoft can lead to some problems in lack of interactivity, and speedy, potentially ungrateful-seeming code reviews. These minor nitpicks can be fixed, however, and although slightly harm the experience of contributing to corefx, I intend to keep contributing.