Building with clang on Win32

256 views
Skip to first unread message

Neil Hodgson

unread,
Sep 6, 2016, 1:13:24 AM9/6/16
to Scintilla mailing list, scite-i...@googlegroups.com
Its getting easier to build Scintilla and SciTE on Windows with clang. clang 3.9.0 for Windows can be downloaded from http://llvm.org/releases/download.html

These rely on Microsoft headers. My machine has multiple copies of Visual Studio and Windows SDKs installed so I don’t know how to make a minimum install.

Building requires a copy of GNU make and windres and these can come from an installation of MinGW. I haven’t tried MinGW-w64. 64-bit clang can’t link with a 32-bit resource file made by MinGW GNU windres so I haven’t built executables with 64-bit clang, only 32-bit. The 32-bit executables work fine although I haven’t tested much.

Patch files from the current Scintilla and SciTE makefiles are attached. To run mingw32-make and windres, the bin directory of MinGW is in my global path. To access Microsoft headers and tools, I open the “VS2015 x86 Native Tools Command Prompt” and then run “mingw32-make -f makefile.clang CLANG=1” inside scintilla\win32. SciTE is similar. The changes to the SciTE makefile are lower quality and just build with clang while the Scintilla makefile can choose based on the presence/absence of CLANG=1 on the command line.

Microsoft’s headers aren’t happy unless C++14 mode is on and they lead to many warnings for standard string functions unless _CRT_SECURE_NO_DEPRECATE is defined. Other differences include MinGW wanting some different link flags and the stdc++ library (a c++ lib is assumed by clang or MS). clang doesn’t have -s for strip. The directory where clang is installed is hardcoded into the CXX and CC variables and match a 32-bit installation - "Program Files (x86)” -> “Program Files” for a 64-bit installation. An alternative would be to have all three compilers in the path but I haven’t got that to work yet.

This is all a bit fiddly but I thought others may want to use clang. There are a couple of uninteresting warnings for using the __uuidof language extension and not using a private field. While the attached changes could be made to the repository, I’m hoping that there will be cleaner ways to allow building with clang in the future, possibly with a more complete and isolated clang download.

Neil
clangmingscite.patch
clangming.patch

David Macek

unread,
Sep 6, 2016, 2:38:24 AM9/6/16
to scite-i...@googlegroups.com, scintilla...@googlegroups.com
On 6. 9. 2016 7:13, Neil Hodgson wrote:
> While the attached changes could be made to the repository, I’m hoping that there will be cleaner ways to allow building with clang in the future, possibly with a more complete and isolated clang download.

Hi. Adding clang to the list of supported toolchains sounds great. Please don't forget that clang doesn't imply MS headers. There are also pure clang/mingw-w64 toolchains, such as the one provided by MSYS2. If you don't have time to consider this combination in your changes, I'll understand and I'll try to come with relevant patches myself later.

Cheers.

--
David Macek

Reply all
Reply to author
Forward
0 new messages