At Epic we’ve been working on adding support for the latest Clang compiler on Windows platform. Some version of Clang is already used on most other platforms, but getting Clang running on Windows makes it easy to use some of Clang’s excellent diagnostic features, and perhaps eventually to allow you to compile game modules without requiring Visual C++ to be installed. Of course, we’ll always continue to support Visual C++!
So the Clang team has been making great improvements over the last couple of months on Windows support. It’s actually getting pretty close to parity with Visual C++, though quite a few bugs remain.
I thought I’d share the current state of compiling UE4 using Clang on Windows so far with you guys! If you grab the latest code from GitHub master branch (as of 12/19/2014), you can try this out if you’re interested!
To use Clang on Windows:
Install the latest Clang compiler (click ‘Windows Installer’.)
Open UEBuildWindows.cs. Set bCompileWithClang=true.
Rebuild!
Cool stuff:
You can now use Clang to compile, link and run most small UE4 programs (SlateViewer, UnrealHeaderTool, UFE, etc) on Windows.
You can now use Visual Studio to debug Clang-compiled code, as long as you use the Visual Studio linker (the default setting).
Clang now has full compatibility with Microsoft’s C++ object format. This means it can seamlessly link with code compiled with VC++, such as third party libraries.
Bad stuff:
The full UE4 editor doesn’t compile yet, mainly due to some parsing issues with DirectX header files and also some issues with system include paths (XAudio). We should hopefully be able to fix this.
Precompiled headers aren’t supported when compiling with Clang on Windows yet. There are several bugs in the Clang compiler preventing this. This means compile times are currently very slow!
We still require and use the Windows “resource tool” (rc.exe) and lib tool (lib.exe), even when compiling and linking using Clang.
We still require the Windows SDK headers and libraries. This means you must have the Windows SDK or Visual Studio installed in order to build with Clang. I don’t yet see any reasonable way to avoid this when compiling applications that use the standard C library, or anything that links against UE4 code.
If you use the Clang linker (LLD), you won’t be able to debug using Visual Studio yet (no PDB support.)
IncrediBuild (XGE) occasionally has troubles when compiling using Clang on Windows. So you might want to disable XGE if you see strange errors.
Tweakables:
UEBuildWindows.bCompileWithClang - When enabled, compiles code using the Clang compiler. The Visual C++ compiler will not be used at all, but by default we’ll link with the VC++ linker (which supports debug symbols)
UEBuildWindows.bAllowClangLinker - Turns on the Clang linker (LLD.exe). You can now link UE4 programs with this, but you won’t be able to debug in Visual Studio.
UEBuildWindows.bUseVCCompilerArgs - By default we use ‘clang-cl’ to invoke the Clang compiler, which is a shallow wrapper around Clang that handles Visual C++ command-line arguments. If you switch this off, we’ll instead invoke Clang.exe directly using normal GCC-style arguments.
Note: We now support both ‘clang-cl’ (the Clang wrapper binary that supports VC-like command-line parameters) as well as invoking Clang directly ‘clang.exe’ using native GCC-like parameters. I wanted us to support both for now, as each method has different quirks and limitations.
If anyone is interested in this stuff and would like to help out with improving support for Clang on Windows, please chime in or send me a message. It’s a fun and interesting side project that I’m excited about, as there are potential cool powers this could enable in the future. For example, in the future we’d like to replace our naive C++ parsing in Unreal Header Tool with the robust Clang parser, then use the AST to harvest reflection meta-data instead of scraping the code directly.
I have been planning to look at this, anyway. I’ve been running with MSys2 which gives you the pacman package manager on Windows and makes maintaining an up to date clang-based toolchain much easier.
So it appears according to that post the Editor can be build with LLVM clang r231657, for which a windows build is available from llvm.
I didn’t yet try it but it would be awesome to have clang as a real option against the MSC++ compiler and the mingw variants.
What is a real pitty that there’s no C and std c++ library apart from Microsofts, waiting for a Microsoft compiler that does everything according to current standards we’ll probably have a new standard already again.
As of some changes yesterday in master branch, you can compile and run the whole Unreal Editor using Clang on Windows platform.
It still has a way to go, but many of the problems mentioned above are solved (PCHs now work, basic debugging works, all of the Windows and DirectX headers are digestable, etc.) Getting UE4 working on Clang for Windows has been a background project of mine for almost a year. If anyone in the community is interested in jumping in to help improve this new workflow, we’d love that!
Open UEBuildWindows.cs, and change bCompileWithClang to true.
Switch to Debug Editor configuration. (See below for more info.)
Rebuild the game or engine
Notes:
You must use Clang r231657 (3.7.0 alpha). There are no other releases that I’ve found that are able to compile UE4 successfully. Most of the newer releases crash during compiling, and older releases aren’t able to digest Windows header files well enough.
Compiling in Development currently will not work due to bugs with Clangs handling of inlining and DLL exports. Monolithic builds should work, though.
Occasionally you may see runtime crashes (stack overflows or access violations) when running UE4 compiled with Clang on Windows. These may very well be bugs in Clang (remember, we’re using an alpha release of Clang 3.7.0.) Unfortunately without better debugger support, it can be difficult to workaround these
When debugging, you will only have functions and line numbers, no variables or parameters. Clang only has preliminary support for Microsoft’s PDB format currently.
XGE (IncrediBuild) is fully supported with Clang on Windows.
Shared PCHs aren’t supported yet (similar to on Mac and Linux), so iterative compile times may be slower compared to Visual C++. However the Clang compiler is actually quite fast for rebuilds, probably because of missing debug info though.
There may be some compiler warnings that are different between Mac/Linux and Windows. We haven’t done a line-by-line comparison yet.
Build products and executables for Clang and VC++ overlap on disk. So you have to rebuild to switch back and forth. Sorry.
Clang on Windows has a few bugs that we’ve had to work around. You might see some strange things from time to time. Every new release of Clang has different behavior on Windows.
We still use the VC++ Linker, even when compiling using Clang. The new Clang linker (lld.exe) can be enabled with bAllowClangLinker but it will crash when linking some modules. It also doesn’t produce usable debug symbols by Visual Studio (yet).
Almost there, as Mike Fricker said, you still need the Windows SDK tools/headers/libs and the VC linker, and the linker isn’t part of the SDK anymore since Windows 8; and the output isn’t perfect yet. That means you still need VS 2013.
Would be possible to use the windows SDL/headers/lib and linker of VS2012? Im teaching a ue4 programming course in my university, and they cant install VS2013, but have VS2012 installed. Ive been looking at using linux as an alternative.
Right. Many bits of Windows-specific engine code will obviously always depend on the Windows platform SDK header files and runtime libraries. But I’m hoping that in the not-so-distant-future, we can support compiling game modules and engine plugins without requiring the Windows SDK files. We can certainly make our Core headers conditionally not require the Windows headers, but there is a bit of refactoring to do there. And even if we’re successful, we’d still need some of the import libraries from Visual C++, because I don’t see us supporting MingGW. We’ll see. This is just the very first steps. Our goal eventually is to allow people to compile game modules without any additional prerequisites beyond what we ship included with UE4 on either GitHub or through the Launcher. It is definitely a long term thing.
Strange sidebar here. I’m using Visual Studio while learning the ins and outs of the engine because intellisense is useful for learning. Normally, I’m a vim user and although vsVim for visual studio is usable it’s not as smooth or efficient as proper gVim with plugins and my scripts. Great, what does this have to do with windows clang UE4? Well Vim does have great C-family ‘intellisense’ when paired with a plugin called YouCompleteMe. YCM uses libclang on the backend. For this plugin you can write a python file that specifies the compiler flags and things like include directories, but that seems like a lot of directories for UE4, and more importantly I’m afraid it is brittle as the engine changes or I bring different plugins in.
As an alternative to this python file you can instead just feed YouCompleteMe a compile_commands.json file, something usually spit out from CMake or BEAR for non-Cmake projects. Now this feature is in a bit of a strange spot on windows anyway as it seems to only support Make and Ninja style projects, not visual studio solutions at the moment. So my question to you is: despite using clang for the actual compilation is this process still using the visual studio toolchain for the project or is it something closer to make/cmake on unix?
Neither, we use UnrealBuildTool, which is a custom tool that determines what modules and plugins are needed and drives the compilation and linking. In recent versions we do generate a ‘makefile’ to help speed up UBT execution time, only invalidating it when configurations or projects change, or you generate project files again. It’s not a makefile in the traditional sense (something that make can consume), but it might be transformable to something that YCM could consume. Check out Makefile.ubt and the code surrounding it in UnrealBuildTool.cs (e.g., LoadUBTMakefile).
This is a wonderful feature. I am really looking forward to it.
@BlueByLiquid: Clang support for Vs2015u1 is still only with Microsoft CodeGen and limited to .lib and .dll as far as I know. You can add the LLVM backend with clang with the official LLVM installer.
EDIT: I was wrong. You can compile a console app with clang with CodeGen without problems. Just change the Compiler in the property pages.
I use Visual Studio Community 2015 with Clang with Microsoft CodeGen. I tried installing LLVM and Clang, but I couldn’t get it to work. I don’t know how to get to the distributed files. When I tried to compile my code with Clang++ on the Windows Command Prompt, I got an error message saying that it can’t find iostream. Do I use -L to manually tell it to link the file? And if so, how do I tell Clang what file-path iostream has so that it will look there to find and link it?
Also, when the walkthrough for using LLVM says to read the Documentation, is it talking about Documentation inside the downloaded files for LLVM, or an online Documentation?
Edit: As a clarification: I can compile with Clang 3.7 with Microsoft CodeGen from VS just fine. I’m just having trouble with LLVM and the Clang downloaded with it.
Now that Microsoft is supporting Clang directly in Visual Studio, do you expect making the switch to build UE projects with Clang might become more seamless?
