Closed mrhelmut closed 2 months ago
we might just be good with packaging the current pre-built dlls into a nuget and calling it a day
I think this concept is pretty valid if it's near-term enough with the switch. No need to polish something that will go away.
That said, I have one caveat. The current binaries are old enough that I'd at least recommend rebuilding them with newer stuff while in the area. The .16 version will result in various crashes in production (some of which are fatal and hard to pinpoint). As is, I have a duct-tape fork (I honestly don't know what a proper update to MG would entail or I'd have made a PR) with the latest .23 binary to help unlucky players.
When it comes to dependencies, we need to avoid forks and unofficial distributions (because it is not a sane approach to start relying on custom patches), and if the dependency isn't self-building, we (the Foundation) need to built it ourselves to avoid security issues from pre-built binaries.
However, since we are planning to move away from OpenAL
Is there a ticket for that we can track?
This has been done via https://github.com/MonoGame/MonoGame.Library.OpenAL and https://github.com/MonoGame/MonoGame/pull/8466
We would like to retire the dependencies repository/submodule. The strategy is to move each dependency to its own repository which will automatically build it from source, make sure that all platforms are covered and statically linked, and package it into a nuget.
This work has already been done for most dependencies, like SDL.
We need OpenAL-Soft to be adapted to this same structure, and built+validated for the following architectures:
win-x64
,linux-x64
,osx-x64
,osx-arm64
,android-arm
,android-arm64
,android-x64
(for emulators only).However, since we are planning to move away from OpenAL, we might just be good with packaging the current pre-built dlls into a nuget and calling it a day. Thoughts on that?
If anyone wants to look into this, hit me up and I'll create a MonoGame.Library.OpenAL repository.