Header sorting is not going to work for the Cycles kernel. It's used to compile the entire kernel as a single file, and the order there matters.

I guess we can sprinkle some /* clang-format off */ in the code there, unless there is a way to disable this for entire directories.

If it's just a handful of files, /* clang-format off */ seems preferable over copying the entire configuration.

I was updating the patch based on buildbot and missed your replies.
I will try /* clang-format off */ here and there, good call.

Cycles works after rBc8ac760c590a: Cleanup: tweak Cycles #includes in preparation for clang-format sorting.

The simplest solution is just to add an empty line and put BLI_winstuff.h at the top, which I think is acceptable.

#include "BLI_winstuff.h"

#include "BLI_a.h"
#include "BLI_b.h"
...

Adding BLI_ftell and similar would be even better, if it can be done without delaying this patch more than a week then I would try that.

I have a patch ready for the file functions (will get that posted tomorrow), but ran into a second issue that must be resolved HKEY we define it, the windows headers define it and we have been fighting with it ever since, i'm not sure why nobody ever renamed these in enum members

we have in a single enum

EVENT_NONE = 0x0000,
LEFTMOUSE = 0x0001,
WM_IME_COMPOSITE_START = 0x0014,
TABLET_STYLUS = 0x001a,
ZEROKEY = 0x0030,  /* '0' (48). */
HKEY = 0x0068, /* 'h' (104). */
NDOF_MOTION = 0x0190, /* 400 */
EVT_ACTIONZONE_AREA = 0x5000,       /* 20480 */

it kinda feels like we have we just given up here?

To get this patch rushed in (although I don't understand why we are suddenly rushing this) we can probably get away by just renaming the HKEY to perhaps BWM_HKEY (WM_* is out of the question, that's just more collisions with the win32 api waiting to happen) but this be a good candidate for a code quality friday.

Also i'm gonna just call this, none of the issues i am running into are due to recent code changes, all these are things that have been real fragile for a long long time, there is a 0% chance this diff was ever tested on windows, unless there is a real good reason not to deal with the underlying issues, i'd really prefer stalling this patch until these issues (and whatever may still come up) are properly dealt with.

Hi Ray, thanks for looking at that.

Although I don't understand why we are suddenly rushing this

This will always be disruptive. bcon2 is a moment where at least the main big patches that were on the verge to be committed are already in. So just trying to be the least disruptive as possible as far as merge conflicts go. Specially because of LTS I would rather see this in 2.83.

We can probably get away by just renaming the HKEY to perhaps BWM_HKEY (WM_* is out of the question, that's just more collisions with the win32 api waiting to happen) but this be a good candidate for a code quality friday. (...) Unless there is a real good reason not to deal with the underlying issues, i'd really prefer stalling this patch until these issues (and whatever may still come up) are properly dealt with.

I would rather not wait a whole 3 weeks to fix that. If it is really only renaming I can take an hour or two aside and tackle that myself.

On having tested this on Windows.

I did set it to build, but maybe it was when buildbot was failing due to code signature. Anyways, as you pointed out, I clearly haven't gone through the proper testing since you are running into these.