Build Clang in Visual Studio. Part 1

Mykola Volodymyrovych
5 min readJun 14, 2023

--

🐌
Yours truly is not an expert in compilers, but does enjoy diving into this topic and learning something new from time to time.

This post is split up into 3 pages.

Introduction

The Clang project provides a concise, easy-to-follow guide on building and running Clang on Windows using Visual Studio. Simply stick to the outlined steps to obtain a VS solution that you can build and debug just fine. However, changing a few of these steps slightly can improve the experience of working with the solution even further. Additionally, I’d like to highlight a couple of points that are mentioned in the docs but are relatively easy to overlook. (At least, I did manage to miss them the first ten times reading that page…)

Dependencies

The guide outlines 5 build dependencies of Clang: Git, CMake, Visual Studio 2017, Python, GnuWin32 tools. We’ll need to get all but one of them installed before getting on to cloning and building the sources.

Git

That’s in the unlikely case, you don’t already have it on the machine. Maybe Linux or Mac is your daily driver, but for whatever reason, you need a Windows build of Clang. A web search will take you either to Git’s official page or Git for Windows. The info on the Web comparing the two distributions is outdated and confusing. Apparently, there used to be differences in the past, as evident from this answer. However, both pages point to exactly the same Windows port of Git today, and have been for a while now.

CMake

Not much to say about it. Download the installer of the latest stable version from the official site and you’re good to go.

Visual Studio

The community edition is free for personal use. The latest stable version is a good choice as usual. During installation, don’t forget to check on the Desktop development with C++ workload, and the latest Windows 10 or Windows 11 SDK depending on your system. Installing both most likely won’t do any harm either, but I haven’t tried that myself.

Python

The guide suggests getting Python from the official page. Installing it like that sure gets the job done. But hold on for just a minute.

Having a single version of Python installed system-wide or per user is a potential invitation for version-compatibility-related problems. If you have your own projects or third-party software that depends on different versions of Python, especially if some of these are on the Python 2 series, they are going to conflict with each other. And maybe¹ even break the Python installation.

With the above in mind, using a Python version manager pyenv for Windows might sound like a good idea. Of course, pyenv comes with its own downsides. Notably, Python is invoked through a layer of shims (Ew!). To top it off, CMake configures Clang's sources with a path to Python executable. We'll have to manually supply that path to Python, or rather to its shim (Ew!).

Installing pyenv for Windows

If you agree, here’re the steps

# Allow execution of remote-signed powershell scripts, so we can run the installer.
PS > Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine

# Download and run the installer.
PS > Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/pyenv-win/pyenv-win/master/pyenv-win/install-pyenv-win.ps1" -OutFile "./install-pyenv-win.ps1"; &"./install-pyenv-win.ps1"

Reopen the command prompt [or powershell] and run pyenv --version Now type pyenv to view it's usage [...] For Visual Studio Code or another IDE with a built in terminal [or any standalone terminal], restart it and check again

Validate installation

Should you run into a bump, consider immediately reminding yourself what a great time together with the version manager you’re about to have. Then give the links below a shot, they may help with troubleshooting.

Installing Python

Now, that we have a version manager, it’s time to install Python.

# This gives the list of Python version available to install
PS > pyenv install -l

# Install Python 3.11.3 -- the latest stable version at the moment of writing.
PS > pyenv install 3.11.3

# Set Python 3.11.3 as the global version.
# Remember to restart the relevant apps
# From now on, an invokation of Python from any process
# is going to be "redirected" to the globally set version.
PS > pyenv global 3.11.3

GnuWin32 tools

The reason Clang’s getting started guide lists GetGnuWin32 as a build dependency is “[t]he Clang and LLVM test suite[s] use various GNU core utilities, such as grep, sed, and find."

GetGnuWin32 is a package manager. GnuWin32 is the package repository project used by GetGnuWin32, the repository “provides ports of tools with a GNU or similar open source license” to Windows. grep, sed, and find are among these ports.

Unfortunately, it appears both projects are abandoned. GnuWin32 last updated a package back at the end of 2010. Latest version 0.6.30 of GetGnuWin32 was released in 2009 (only the bundled OpenSSL package was updated to openssl-1.0.2n.zip at the end of 2017).

While according to the guide “[t]he gnuwin32 packages are the […] most well-tested way to get these tools”, I still don’t believe using GetGnuWin32 is an appealing option nowadays:

  1. Yes, tools like grep, sed, and find don't change that often, if at all. But the packages are still extremely dated.
  2. Maybe using ancient packages is not that big of a deal after all. But the thing is, as the guide itself informs us, all the required tools come bundled with Git for Windows. Thus, installing an additional dependency is pointless.

The test suites automatically detect the path to Git for Windows’ tools. Assuming you installed Git for Windows into the default location, that path is C:\Program Files\Git\usr\bin. Additionally, it's always possible to add C:\Program Files\Git\usr\bin to PATH, in case autodetection experiences a hiccup.

Continue on to Part 2. Generating a solution and building it.

[1]: I’m not sure on this one, though I can imagine a way it can happen. Anyhow, I certainly am not looking forward to figuring out an issue with a Python installation I likely don’t even remember exists on my system.

--

--

Mykola Volodymyrovych

Hi there! My name is Mykola. I'm a software developer. My standalone blog is over at https://mykolam.net