So I have a concern about unity builds based on your explanation.

Right now, I find it a common occurrence to have different compilers, build systems and os behave differently. This can be due to GCC and clang not agreeing, or more commonly msvc strictly adhering to the standard, sometimes it's due to different oss and the system libraries... Many reasons.

I am a bit concerned that this will add yet another way that the code will work on my machine (doing incremental compilation) and not on the ci, as debugging based on GitHub's output is not a pleasant experience!

These are valid concerns! Yet another configuration that may behave differently is definitely something to be weary of.

FWIW I don't suggest that we move all CI to a unity build... but if it is significantly faster, we could move most of CI, and leave one non-unity build for testing. I think it is worth discussing before we move this further.

@jrsurge do you have any suggestions here? Adding another build configuration that may behave slightly differently is a concern and we don't want to create more maintenance burden.

I think it is worth discussing before we move this further.

It sounds like you want to run this as an experiment? It that case, since reverting something in the build system is so easy, I say just do it and see what happens!

No need to discuss something we don't have enough information about yet!

Fyi, the enum conflict is due to a namespace issue, if you add using TokenType = SC::lex::TokenType the issue disappears.

The problems with the yy* vars seems real though, the bison generator makes a tone of globals, we have two grammars, sclang and the docs, I believe this necessitates odr violations??

Thanks!

Fyi, the enum conflict is due to a namespace issue, if you add using TokenType = SC::lex::TokenType the issue disappears.

Hm, are you sure? The issue is that our definition leaks into Windows headers, IIUC, e.g.:

2026-05-12T18:24:03.5811014Z C:\Program Files (x86)\Windows Kits\10\Include\10.0.26100.0\um\winnt.h(12059,5): error C2365: 'TokenType': redefinition; previous definition was 'typedef' [D:\a\supercollider\supercollider\build\lang\libsclang.vcxproj]
2026-05-12T18:24:03.5812750Z (compiling source file '../../lang/CMakeFiles/libsclang.dir/Unity/unity_1_cxx.cxx')

As for the macro conflicts, do you think they should be solved in the code (pop/push macro) or is it fine to just exclude these files from the unity build like I'm proposing right now?

The issue is that our definition leaks into Windows headers, IIUC, e.g.:

Ah yes I'm still not 100% sure how they work. Assuming it's the TokenType from the new lexer, then it's in a namespace so can't collide (unless they also have a sc::lex namespace). So if all the files are being stitched together, then we might just have to remove a using declaration somewhere.

I've only ever used undef with macros, but it's with a go?

What I'm concerned about is constantly adding to this list. We should try to get everything working correctly first... but if you just wanna see what happens and if it affects development then I'm also fine with merging now!

We should try to get everything working correctly first...

Do you mean - unity build working correctly by excluding files? Or fixing files so that they we don't populate conflicting names/macros into windows headers?

Fixing the files