-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Updated Native targets to detect architecture for arm builds. #2695
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
base: master
Are you sure you want to change the base?
Conversation
The dlls were built using `sources\tools\Stride.TextureConverter.Wrappers\build-deps.bat` inside of developer command prompt of VS2022
The logic was taken from dotnet/msbuild#5065 (comment) which seems to be the only solution to detect architecture. Sorry to ping you again @azeno but since you seem to have an arm system can you give this a try to make sure it works as I hope? |
Can this PR be rebased? It seems to include the same change that was done in #2694. |
Thanks to the wonderful jkao for pointing out my silliness in Discord it should be good now. |
…into update-build-config
|
Gotcha makes sense, in that case I think the below code change should be fine so that it only runs when the conditional is true:
And the default behaviour is just to use the hardware metadata to determine the result. |
Another assumption that maybe Im misunderstanding is that I thought you would need an arm system to build the arm libraries. If that isnt true am I missing something to be able to do a full build for this? I already installed the arm related |
Did you install the ARM64 (not ARM) MSVC v143? I did it this afternoon on a win-x64 machine and it worked just fine. |
I haven't checked what the current state is of what this PR changes, but ideally we should have this by default:
In other words, running msbuild manually on a user machine should only build what's necessary for that user machine, therefore detect the proper settings. |
Ok, this PR should still be relevant then. It adds a toggle to enable or disable arm builds and if no setting is provided it uses the developers host machine to determine if it should be enabled. The default for the Stride.Build file is to have it true so it should be on for TC builds. |
Your proposal doesn't include the other way round, where on an arm64 machine the x64 targets are optional. Since I'm currently sitting in front of a x64 machine and arm64 machine, I can have a look if you want and post the results here. |
Is that because there are more configuration changes needed outside of If you have time to test it that would be awesome as I dont have valid hardware to test natively. |
Ok, turns out the other way round (no x64/x86 on arm64 host machine) is not really an option as they are a requirement for other packages.
|
Ah nice, that is a ton more clean then what I ended up with. Although is just |
As far as I know there's only ARM64 on Windows, ARM32 is getting phased out. |
Is this PR ready to be merged ? Looks like a no ? |
I had to replace my PC so I completely forgot about this. I think I just need to test Azenos solution and update it and we should be good. Ill finish this in the next hour. |
Ok, this should be good to go now. Tested with and without the ARM64 build tools and everything works as expected with Azenos above code. |
I dont think any of my changes here should have affected OVR but I did notice the csproj for VR is the only one that contains false explicitly for arm builds?
No clue if thats actually the problem though as it works locally for me. |
PR Details
The default build was setting itself to always be for arm even on non-arm systems. This change should allow users to build and have it detect whether or not they need the arm build enabled.
The architecture information was taken from https://learn.microsoft.com/en-us/dotnet/api/microsoft.build.utilities.processorarchitecture?view=msbuild-17-netcore although they did not include X64 which is required after some testing.
Related Issue
#2694
#2693
Types of changes
Checklist