Add conditional dependency on LLVM packages for Mono #2140
Conversation
|
Oh, forgot to add it to CI, too. I'll do that... |
directhex
force-pushed
the
mono-llvm-enablement
branch
3 times, most recently
from
7821c22 to
5eec654
Compare
eng/Version.Details.xml
Outdated
There was a problem hiding this comment.
I don't think we need to list all platforms/architectures here, the runtime.native.System.IO.Ports on line 19 doesn't do it either. We might need to change how we're producing that package.
There was a problem hiding this comment.
runtime.native.System.IO.Ports is a metapackage, and we don't have a metapackage for LLVM. We can add one, sure
There was a problem hiding this comment.
Yeah I think we should do that.
There was a problem hiding this comment.
We should as the same package will be used for AOT tooling packages
There was a problem hiding this comment.
We're going to use one metapackage to pull in AOT support (i.e. llc and opt binaries) for every single supported architecture in one go?
There was a problem hiding this comment.
No, it will be RID driven for host (and possibly target) but the package should be identical to our internal dependency
There was a problem hiding this comment.
That's the split already in place here - runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk contains LLVM for build-time (i.e. what we need internally to compile LLVM JIT Mono), runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools contains opt and llc, the two binaries needed for LLVM AOT support (i.e. end users would receive this, one way or another). If we want to rename things, I'm open to suggestions.
directhex
force-pushed
the
mono-llvm-enablement
branch
2 times, most recently
from
67a6a44 to
7069651
Compare
These are only restored or used when /p:MonoEnableLLVM=true
directhex
force-pushed
the
mono-llvm-enablement
branch
from
f642c92 to
5180448
Compare
directhex
force-pushed
the
mono-llvm-enablement
branch
from
7e00cb4 to
6201ac9
Compare
|
Okay. We're green, and building LLVM Mono. I'm going to try and get LLVM metapackages generated today, for cleaner dependency handling, but will mark this PR as not-draft tomorrow regardless of status (the metapackage is a nice-to-have, but explicitly not a blocker on functional LLVM builds) |
Co-Authored-By: Alexander Köplinger <[email protected]>
Co-Authored-By: Alexander Köplinger <[email protected]>
|
Those aren't my failures, they're the usual infra breakage. I'm trying & failing to figure out how to drive the metapackage ("lineup package") creation functionality in Arcade. |
|
The hell are some of these failures? I haven't touched CoreCLR Windows |
directhex
force-pushed
the
mono-llvm-enablement
branch
from
5a2b296 to
29b16e7
Compare
directhex
force-pushed
the
mono-llvm-enablement
branch
from
29b16e7 to
068bb0f
Compare
|
I can't get Helix to give me the failure log from that run, I just get blob not found errors |
|
OK well I guess the failures I was getting were flakes |
ghost
locked as resolved and limited conversation to collaborators
7 participants
These are only restored or used when /p:MonoEnableLLVM=true
Creating as draft for now - there's one breakage I want help with (the restore only copies LLVM to the staging tree the second time it's run)