Native Extensions + Win32 + Clang



Since the release of 1.2.133 we now support building
the extensions for Windows with Clang.

It has some very good benefits:

  • We get a more unified pipeline
    • We can build all our platforms with the same compiler
  • Faster turnaround times for windows builds
    • The old build was about 10x slower on the extension server
  • Easier to develop cross platform extensions
    • You’ll write less platform specific code

How to use it

We’ve currently added a flag use-clang to control usage of the new compiler.
The current default value is false. You can add it to the app manifest like so:

            use-clang: true
            use-clang: true


We intend to phase out the old Windows build tools (CL.exe/LINK.exe) entirely in a few steps.

  • Currently
    • The special flag: use-clang can be added to test your extension for compatibility
    • Defaults to false
  • October 1’st
    • The default value is changed to true
  • (Preliminary: December 1’st)
    • We remove the flag altogether!

What does this mean for you?

Extension Developers

If you are a developer of an extension, make sure your extension builds with clang now to ensure that the end users can use the extension without disruption.

Extension Users

Ideally, you shouldn’t have to do anything at all.

But to make sure your native extensions will work with clang, it’s recommended that you use an app manifest and add this to your project, and also use the use-clang flag.

If you find that one of the native extensions you use doesn’t compile with clang, contact the developer of the extension and register an issue with them.

It might also be good to report non-working extensions here, so we can all keep track of progress.

How to create a Windows release build?
Problems with sprites in html (SOLVED)


A gentle reminder that we’re nearing the switch to use clang as default compiler for WIndows builds.
I see on the server that there are still builds that take up to 5 minutes (!) and I’m hoping that those are using native extensions without even knowing it (it’s a powerful feature :slight_smile: ).

But, for those of you that maintain native extensions for Windows, please take a few moments to verify that your extension builds using clang. You can use the Manifestation tool to see how the use-clang flag is used.


None of the NEs I’ve tested so far have had any issues with Clang. The builds are super fast! Big thank you!!


Looks like clang still not a default compiler for win32?


Yes, unfortunately :slight_smile:
I’ve been playing catchup with a few other issues, and haven’t had time to dedicate to this endeavour.
(also, I’d like to do some research while at it)

But, it’s not far off now!


Update: Clang is now the default compiler for Win32

I’ve now released a new server, which should be up and running within a few minutes.
Here, the Win32 builds are using Clang as default.

So far, we’ve had no issue reports from developers regarding this, but please send me a message if anything breaks for you.

As a first step, if you would need to temporarily go back to using CL.exe/Link.exe, you can do so by setting the flag use-clang: falsein your app manifest.


As expected, the performance gain was quite dramatic for our users:
Previously, a Win64 build took 2-4 minutes, now it takes 5-10 seconds:



Graph (the change is ~16:00):


A friendly reminder that we’re closing in on December 1, where we’ll disable the CL.exe pipeline.
After that, every Windows build will be done with Clang.

Most of you are already using Clang, but I can see a few builds per day in our logs where it takes ~3-6 minutes. If you have an app manifest with clang: false, I urge you to try removing that now, to make sure you can build properly with the new pipeline. Your build should speed up dramatically!


How can some extension use clang, when some others don’t?


I’m not sure I understand?

Using clang is the default behavior. So if you don’t specify anything, you are automatically using clang.

Now, after December 1, everyone will be using clang as the compiler. So make sure your extensions work properly before then. If you run into any issues, please let us know, so we can help resolve it.


Configuring clang in app manifest will affect all the extensions, In the same project, I want one extension using clang, but other extensions not.


Well, clang is used on all extensions.
What is the reason you feel you cannot use clang for those extensions? Do they get compile errors?


Right now, I have one extension that works improperly when open clang in win32.


Ok, I’d love to help out!
Is it a repository you can share? Or perhaps share the compile errors with us/me?

The speedup when compiling is worth it alone imho (3+ minutes down to a few seconds)


All the extensions can compile with no error whether clang is open or not.I just can’t work properly when clang is open.Due to the fact that after December 1, all extensions will be compiled using clang whether clang is open or not in the app manifest, My workmate is fixing this issue in the extension.
Just forget it.Thanks.


Ok. The usage of clang is currently controlled in the game.appmanifest, using the flag “use-clang: true” (As seen in the first post in this thread). However “true” is the default value now, and soon, we’ll remove the option entirely. We haven’t heard any reports of any extensions that cannot be compiled with clang after some minor fixes.



Although we missed the preliminary deadline of disabling the cl.exe builds on December 1st, I’m here to tell you that I’m now removing the support for the “use-clang” flag altogether. We will only support building win32 with clang from now on.
I expect to release a new server with this feature tomorrow.