Native Extensions + Win32 + Clang


#1

Why

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:

platforms:
    x86_64-win32:
        context:
            use-clang: true
    x86-win32:
        context:
            use-clang: true

Upgrading

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)
#2

#3

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.


#4

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


#5

Looks like clang still not a default compiler for win32?


#6

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!


#7

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.


#8

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:

Before:
19

After:
38

Graph (the change is ~16:00):


#9

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!