| Summary: | [Win][Meta] Build WebKit using Clang | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Don Olmstead <don.olmstead> | ||||||||||||||
| Component: | Tools / Tests | Assignee: | Fujii Hironori <Hironori.Fujii> | ||||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||||
| Severity: | Normal | CC: | Basuke.Suzuki, Hironori.Fujii, ian.grunert, lforschler, webkit-bug-importer | ||||||||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||||||||
| Version: | WebKit Nightly Build | ||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||
| OS: | Unspecified | ||||||||||||||||
| Bug Depends on: | 170833, 171751, 171752, 171864, 173889, 189398, 189399, 189402, 189538, 189539, 189542, 189575, 189612, 189693, 189730, 189732, 189733, 190514, 190744, 191146, 191959, 191960, 192581, 192583, 192584, 192617, 192618, 192688, 192693, 192695, 192924, 193029, 193035, 204831, 234696, 255449, 259090, 259096, 259097, 259098, 259119, 260376, 261297, 262154, 262506 | ||||||||||||||||
| Bug Blocks: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Don Olmstead
2017-05-03 14:14:28 PDT
Created attachment 349006 [details] WIP patch > perl Tools\Scripts\build-webkit --release --wincairo --ninja --cmakeargs="-DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64" Created attachment 349010 [details]
WIP patch
I uploaded build logs showing all compilation errors. https://gist.github.com/fujii/ea5a60634e44f9c2a84cf3d3de95e2ad I'm using LLVM-8.0.0-r339319-win64.exe. LLVM Project Blog: Clang is now used to build Chrome for Windows http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html I believe this is the right direction WinCairo port should follow. Created attachment 349627 [details]
WIP patch
Compiler macro definitions should be rethought.
Current definitions:
WTF_COMPILER_GCC_OR_CLANG 0
WTF_COMPILER_CLANG 1
WTF_COMPILER_MSVC 1
* It is weird WTF_COMPILER_GCC_OR_CLANG is off even though WTF_COMPILER_CLANG is on.
* Should WTF_COMPILER_MSVC be on?
Here are the built-in macro definitions of Clang for Windows: _MSC_VER: 1914 __GNUC__ is not defined __clang__: 1 clang version 8.0.0 (trunk) Target: x86_64-pc-windows-msvc check program: https://gist.github.com/fujii/4547bda099b3568f46ee164674b1f60d Using clang-cl to ship Windows builds - Google Group https://groups.google.com/forum/m/#!topic/mozilla.dev.platform/wwO48xXFx0A 1443590 - Use clang-cl for Windows builds we ship to users https://bugzilla.mozilla.org/show_bug.cgi?id=1443590 glandium.org » Blog Archive » Firefox is now built with clang LTO on all* platforms https://glandium.org/blog/?p=3888 Created attachment 350006 [details]
WIP Patch not to define WTF_COMPILER_MSVC
WTF_COMPILER_GCC_OR_CLANG 1
WTF_COMPILER_CLANG 1
WTF_COMPILER_MSVC 0
Created attachment 350007 [details]
WIP Patch to define WTF_COMPILER_MSVC
WTF_COMPILER_GCC_OR_CLANG 0
WTF_COMPILER_CLANG 1
WTF_COMPILER_MSVC 1
Comment on attachment 350006 [details]
WIP Patch not to define WTF_COMPILER_MSVC
It seems safer that Clang for Windows builds the same code path with MSVC in the transition phase.
WinCairo port can be built by Clang for Windows (with zillions of compilation warnings). https://trac.webkit.org/r236450 I took benchmarks: ARES-6: MSVC: 37.24ms Clang: 35.85ms (faster) Speedometer: MSVC: 59.38 (faster) Clang: 56.9 (I needed some trial for Clang because Clang built executable is unstable and did finish the benchmark.) Build Time: Ninja+MSVC: 30min (much faster) Ninja+Clang+link.exe: 50min (In reply to Fujii Hironori from comment #11) > (I needed some trial for Clang because Clang built executable is unstable > and did finish the benchmark.) did not finish (In reply to Fujii Hironori from comment #12) > (In reply to Fujii Hironori from comment #11) > > (I needed some trial for Clang because Clang built executable is unstable > > and did finish the benchmark.) > > did not finish I was wrong. MSVC builds are also unstable for the benchmark. This is not Clang builds issue. (In reply to Fujii Hironori from comment #11) > Build Time: > > Ninja+MSVC: 30min (much faster) > Ninja+Clang+link.exe: 50min This slowness is caused by the zillions of compilation warnings. If I apply the part of Comment 8 patch to suppress the warning, the build time becomes comparable. > ==================================================================== > WebKit is now built (32m:13s). > ==================================================================== How to: Debug an Executable Not Part of a Visual Studio Solution | Microsoft Docs https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-3.0/0bxe8ytt(v=vs.85) * Set up http://releases.llvm.org/download.html#7.0.0 LLVM-7.0.0-win64.exe Add path to clang-cl and ninja * Build set CC=clang-cl set CXX=clang-cl perl Tools\Scripts\build-webkit --release --wincairo --ninja * Remaining Tasks - Create a Docker image with clang-cl - Fix more compilation warnings This is a blocker for Clang 9. Bug 201759 – [Win][Clang 9][MiniBrowser] comip.h(174,16): error: conflicting types for '_com_ptr_t' Keep you clang-cl 8.0.1 at the moment. New blocker: Bug 204831 – [Win] lld-link: error: /manifestdependency: is not allowed in .drectve Can we close this now? There are still remaining compilation warnings. And, I'm maintaining internal WinCairo clang-cl Jenkins jobs, but there is no public bots using clang-cl. So, I'm using this ticket to let anyone know the current status. https://trac.webkit.org/wiki/BuildingCairoOnWindows#CompileWinCairowithClang When will WinCairo bots switch to Clang? The MSVC lambda bug is annoying. (Bug 209358) LLVM 12.0.0 was released. I upgraded it for all internal Jenkins workers. I upgraded the internal Jenkins workers to Clang 13.0.0. The latest WinCairo can't compile with Clang. Bug 234696 – [Clang][Win] NotificationData.h(47,5): error: reference to 'UUID' is ambiguous Build time: > perl .\Tools\Scripts\build-webkit --debug --skip-library-update --no-fatal-warnings 263045@main MSVC: 22m:13s Clang: 25m:16s Size of WebKitBuild directory: $ du -hs WebKitBuild/Debug MSVC: 14G Clang: 7.5G This blocks FTL on windows (bug 145366) - the generated AirOpcodeGenerated.h contains code that builds on clang but warns on MSVC. Could fix the generator to stop spitting out switch statements with a default case and no case labels, but it might be easier to wait till the switch to clang happens? Went ahead and fixed those switch statements in bug 259429 Created attachment 467870 [details] "-T ClangCL" patch It's possible to use CMake Visual Studio generator and clang-cl extension. However, there are two problems at the moment. 1. You have to apply a patch to set "-T ClangCL" CMake switch. 2. CMake Visual Studio generator ignores some compiler warning disabling switches like /wd4100. It reports compiler warnings. You have to give --no-fatal-warnings switches. How to build WebKit Windows port with Visual Studio and clang-cl 1. Install LLVM extension. https://learn.microsoft.com/en-us/cpp/build/clang-support-msbuild 2. Apply the "-T ClangCL" patch 3. Invoke "perl .\Tools\Scripts\build-webkit --no-ninja --no-fatal-warnings" in WebKit command prompt. Or, you can open the solution file: 3. Invoke "perl .\Tools\Scripts\build-webkit --no-ninja --no-fatal-warnings --generate-project-only" in WebKit command prompt. 4. Invoke "devenv WebKitBuild\Release\WebKit.sln" in WebKit command prompt. We don't need the patch.
> perl .\Tools\Scripts\build-webkit --debug --no-fatal-warnings --no-ninja --cmakeargs="-T ClangCL"
The build instruction has been updated. https://github.com/WebKit/Documentation/commit/739ce4449adb3de8e272a4221b67468b404644e2 No remaining tasks. Closed. |