-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Add --os and --arch in VMR build script #48591
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
Conversation
cc @ViktorHofer, @tmds Current experience is not very nice when it comes to cross-build. Even for portable RID linux-riscv64, it doesn't infer architecture from --rid and we have to explicitly spell out the property name (Noticed it while testing dotnet/runtime#114285 here: https://github.com/am11/dotnet-riscv/actions/runs/14551082308/workflow) |
Please add them to build.ps1 and add the long forms as well (target-os, target-architecture). Would also be good if you could update the vmr-build.yml and use them. |
When I'm working later this week, I'll share what flags we're passing in our builds to provide some empirical data. |
d9a717f
to
a1101ae
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.
Thanks 👍
Since @ViktorHofer already approved the PR, I wanted to have a look already at what we're passing in our builds. When we cross-build on Linux with a cross-compilation toolchain we only set We don't seem to be setting Can we also add an argument for |
Also, I opened dotnet/runtime#115002. We might need it in dotnet/sdk as a hint to pick host crossgen2 during the SDK build.
The default for cross compilation is sdk/src/SourceBuild/content/Directory.Build.props Lines 61 to 65 in 5d6ce56
|
Afaik before @jkoritzinsky's changes, nothing in our cross-builds caused Why do some cross-builds need to have this set to When you say it is optional, what does that mean? |
The underlying concept revolve around ROOTFS_DIR. It is required when cross-building runtime, CrossBuild validates it. On mobile platforms, such as Android, we use the compiler from NDK (rather than host compiler with -sysroot=$ROOTFS_DIR), so we don't need it there. Similarly iOS, macCatalyst etc, don't require $ROOTFS_DIR as they require corresponding SDKs to be installed on macOS host (at a per-determinied system location out of our control). Other Unix-likes (desktop platforms), require it, e.g. Linux, FreeBSD and illumos (and soon Haiku).
I meant if we don't specify it, runtime/diagnostics repos infra will figure it out (and issue an error if directory pointed by $ROOTFS_DIR doesn't exist). |
If we can figure out the "kind" of cross build in code, then we can remove this confusion. i.e. CrossBuild / |
Would this help?
to
|
Currently, BuildOS is an RID instead of the OS: dotnet/runtime#114755 (comment). |
And if it were made to match its Arcade definition? |
I see you linked to |
Ah yes. We can update it in runtime once bootstrap changes go in. |
Sounds good. Let's try that instead of adding a |
I think it’s ok to have an explicit |
We can't take any potentially breaking changes right now. Several things need to happen before we drastically change entry points:
I'm happy to take this if we keep it scoped down to OS+Arch. I would recommend to revert the addition of the cross flag if we agree that we can eventually infer it. I'm not yet sold on the necessity for a portable flag CLI arg. Can you please elaborate on why it's usedul as a VMR input parameter? Overall, let's keep in mind that the VMR is an msbuild orchestrator with a super thin script based entry point that only translates args. |
I don't think this PR is required for the next preview. We can merge it when timing is appropriate.
Based on the discussion, we can defer it.
The flag triggers a build configuratie that is expected to work across a larger set of distros. I forgot I already made it part of the default behavior for cross-build. I still think it is useful to increase visibility based on the discussion with the FreeBSD maintainers in dotnet/source-build#5035. |
Also, we like it to be straight forward to use for maintainers. |
@ViktorHofer, I can remove the last commit added after your approval, would that be sufficient to complete this PR? As for cross, as I have explained above, we may need it in SDK as well to resolve dotnet/runtime#115002 and possibly other repos too. Lets keep it explicit it's really not that big of a deal. |
I'm not a fan of requiring arguments that can be deferred from other arguments. I'm fine with removing portable if the use-case is not considered strong enough. I think we should leave out -cross and make an attempt at inferring it. If it turns out too complex, we can still push it to the user. In the meanwhile, adding |
I've reverted portable. None of them are required arguments. |
By required I meant: we require the user to specify an argument the build needs to succeed (which the build can figure out on its own).
I expect this to be doable as I think the main condition is '$(TargetOS)-$(TargetArchitecture)' != '$(BuildOS)-$(BuildArchitecture)'. |
This PR is not forcing a new requirement either, it's giving -p:CrossBuild=true a familiar alias we've been using for years in runtime. |
This means something to someone that is familiar with building runtime repo. What does it mean to the target user of the vmr. |
Right, that's my thinking here as well. Let's leave cross out for now. |
I've tested linux-riscv64 with am11/dotnet-riscv@194e55a and build succeeded https://github.com/am11/dotnet-riscv/actions/runs/14571025407. So CrossBuild wasn't needed for linux on linux with different arch, but needed for different OS on same arch until we modify the CrossBuild condition in runtime. |
Usage goes from:
to: