C# macos support#1576
Conversation
silesmo
force-pushed
the
dev/timmy/csharp-macos-support
branch
3 times, most recently
from
facead9 to
0df3a74
Compare
silesmo
force-pushed
the
dev/timmy/csharp-macos-support
branch
from
0df3a74 to
7373933
Compare
yowl
left a comment
yowl
left a comment
There was a problem hiding this comment.
Just curious about fixing the commit.
| lang: csharp | ||
| runs-on: ${{ matrix.os }} | ||
| env: | ||
| RUNTIMELAB_COMMIT: '4cac3ab5c8e97fda69c23dfca41ace964babc05e' |
There was a problem hiding this comment.
Maybe not, was just for consistency in case the latest version caused something to break. But we can remove it if you want?
There was a problem hiding this comment.
On second thoughts, I agree, lets leave it.
| ./build.sh libs -c Release /p:NuGetAudit=false | ||
| LLVM_CMAKE_CONFIG_RELEASE=$(brew --prefix llvm@18)/lib/cmake/llvm \ | ||
| src/coreclr/build-runtime.sh -arm64 -release -os osx -outputrid osx-arm64 -component llvmjit | ||
| cp artifacts/bin/coreclr/osx.arm64.Release/libclrjit_universal_llvm32_arm64.dylib artifacts/bin/coreclr/osx.arm64.Release/ilc-published/ |
There was a problem hiding this comment.
Interesting, something must be missing in the runtimelab build to make this necessary. Not saying anything needs changing, just if we want to push this to runtimelab, we will have to make the build copy these files.
| <PackageReference Include="Microsoft.DotNet.ILCompiler.LLVM" Version="10.0.0-*" /> | ||
| <PackageReference Include="runtime.{os}-x64.Microsoft.DotNet.ILCompiler.LLVM" Version="10.0.0-*" /> | ||
| <PackageReference Include="Microsoft.DotNet.ILCompiler.LLVM" Version="{ilc_version}" /> | ||
| <PackageReference Include="runtime.{os}-{arch}.Microsoft.DotNet.ILCompiler.LLVM" Version="{ilc_version}" /> |
There was a problem hiding this comment.
This might be a problem for arm64 on windows as we don't have that either.
There was a problem hiding this comment.
Yes this is true. I can add a not supported error for now?
There was a problem hiding this comment.
host arm64 we can do on windows , we use the x64 version and emulation, so maybe condition the {arch} on macOS for now (until we get a native Windows Arm64 build)
|
What is the effect on the build time? An alternative is to push whatever might be needed to runtimelab and will build the nuget there. |
It took 36m 36s But the build of runtimelab took 27m and 43s of that time and it gets cached so it wont take so long for following runs (This is actually a reason to pin it to a specific hash so we don't have to rebuild every time @yowl) |
|
I'm all set up for compiling my exciting new project, a Balatro seed searcher in wasm. Windows build is great, I am set up on MacOS and just noticed all this stuff. What should I do, I'd like to test something you have here just to offer another box to test on, Mac M1 Pro 32GB ram Thanks! |
Up to you really, you can take this branch and build yourself, or wait until this is merged. |
|
Thanks all, it works great...it's really lovely! |
|
@dicej @alexcrichton What do you think about this and the extra time for the build, apparently it should cache the longest bit? |
Seems fine to me if the extra time is minimal when the cache is populated. Is there a plan to move this step over to runtimelab eventually like you mentioned above? |
|
There is no plan to move this to runtimelab due to no one able to support it there.
…________________________________
From: Joel Dice ***@***.***>
Sent: Wednesday, April 29, 2026 3:16:22 PM
To: bytecodealliance/wit-bindgen ***@***.***>
Cc: Scott Waye ***@***.***>; Mention ***@***.***>
Subject: Re: [bytecodealliance/wit-bindgen] C# macos support (PR #1576)
[https://avatars.githubusercontent.com/u/1243153?s=20&v=4]dicej left a comment (bytecodealliance/wit-bindgen#1576)<#1576 (comment)>
@dicej<https://github.com/dicej> @alexcrichton<https://github.com/alexcrichton> What do you think about this and the extra time for the build, apparently it should cache the longest bit?
Seems fine to me if the extra time is minimal when the cache is populated. Is there a plan to move this step over to runtimelab eventually like you mentioned above?
—
Reply to this email directly, view it on GitHub<#1576 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUYCKMPF3R7SBOSATN3MT34YJPJNAVCNFSM6AAAAACXIB2NZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNBXGIYTMMBTHE>.
Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I'm rerunning the macos job in CI to double-check that caching works. So long as this is reliable and at least not slower than the Windows C# job I think it's fine. One minor ask: could the C#-specific setup bits of the CI configuration be moved to something like |
|
Hm, and it looks like the caching may not be working? On the retry it's rebuilding everything it looks like |
5 participants
Build and test it ourselves since it's not a published package based on: dotnet/runtimelab#2119