-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Meta+AK: Add support for AK testsuite on Windows and expose CI utils #4707
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meta+AK: Add support for AK testsuite on Windows and expose CI utils #4707
Conversation
|
FYI @ADKaster |
|
Here is a log of what running |
f96181d to
418b2cd
Compare
|
Also, MSVC supports ASAN (https://learn.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170) via |
|
Ah, looks like there is an issue with Clangs Windows ASAN impl at the moment. We fail to build It looks like LLVM team addressed this in llvm/llvm-project@8417f6a; however, the release this went into looks to be So unfortunately probably need to wait a bit until Visual Studio itself upgrades the version of LLVM it ships with to 20.1.x+ so we can test locally, and then wait for Github Actions to support that Visual Studio version on windows-latest. It does look like Github Actions is planning to add support for LLVM 20.1.x+ in early June, but the one time I tried building ladybird outside of the Visual Studio-based LLVM toolchain things did not go well. Not sure it's worth the effort to support standalone LLVM clang-cl builds when things should just work:tm: if we wait a bit. |
|
If GHA supports VS Preview, I have no qualms about using that. That's what I've been using the entire time to test changes. |
|
Is there an easy way to download llvm from the llvm-project GitHub? They are the same binaries as what VS ships(yes, really). |
|
Anything that's more complicated than "use what's already there" or "Wait two weeks" seems not a good use of time. |
Yes, it is very simple to install, I actually did install the latest LLVM when investigating above so I could try and confirm if the ASAN issue was indeed resolved. But I setup my CLion toolchain to be outside of VS toolset (i.e. the Developer Command Prompt/
Actually, that is a good point, I bet I could use the VS toolset environment still, but point to my 20.1.4 clang-cl install and not use Visual Studios. Let me try that out... |
|
So that means as of actions/runner-images#12001, we can just setup the Windows CI workflow to use whatever current visual studio is available but set |
|
Well what I meant is if there is an easy way to do it in CI. I do use the llvm-project version myself. |
Ah sorry misunderstood, but yeah at that point I feel like Windows CI can just be regular until |
|
Your pull request has conflicts that need to be resolved before it can be reviewed and merged. Make sure to rebase your branch on top of the latest |
418b2cd to
057808e
Compare
|
Tested on Windows via a clean build (modulo removing |
c365ccb to
3403033
Compare
3403033 to
70a5562
Compare
|
Ah sorry only saw your post in |
|
Now depends on some clean up in #4821 |
|
Your pull request has conflicts that need to be resolved before it can be reviewed and merged. Make sure to rebase your branch on top of the latest |
This will allow us to gradually build up official support for Windows, as only targets we have explicitly marked as supported on windows will be built and ran during CI.
We now explicitly enabling support for the minimum libraries needed to build and run the AK testsuite. 81/82 tests are running and passing. The exception is LexicalPath, as some path behaviour on Windows is different than Unix, so the current tests will have lots of platform specific failures. The implementer of LexicalPathWindows recommended windows-specific tests here, so I will do that in a follow up.
70a5562 to
636211f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this change is pretty much ready now, thanks for re-working it on top of my CMake changes

NOTE: This work depends on #4698 being merged into upstream first, but I'm putting it up as a draft for now to get feedback on this approach of gradually getting Windows CI on par with Unix, reducing the chances of Windows bitrot as things are built up.