-
Notifications
You must be signed in to change notification settings - Fork 1
Update to .NET9, add unit tests, rework library loading #2
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
|
I'd appreciate a second review from YDMS so picked @jae1911. |
jae1911
left a comment
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.
Reviewing the changes and the pipelines in your fork, I think that's good.
Thanks for the PR!
|
Alright we're merging! There may be a short delay before we're able to integrate this into Resonite actual, but the work is now 10x easier than before \o/ |
Changes
This PR is large in scope, however the amount of actual changes are quite small. If you would like me to create 3 separate PRs each basing off the last for review purposes, I can do so, but I think one PR should be more efficient in this case.
The GDI libraries and examples are untested as I can't compile them but for GDI/Harfbuzz it should be okay as FrooxEngine doesn't use them anyways.
Update to SDK/.NET 9
I've migrated the solution to use SDK-style projects, gutting out unnecessary flags and files to make them tiny. This is the bulk of the number of lines changed (mostly removals).
I've also made the decision to target .NET 9 since I'm working from a Linux host and I found it unnecessary to keep framework compatibility. This isn't complicated code, so I highly doubt there are any relevant breaking changes.
Add unit tests
I've added some simple unit tests, making sure that at minimum, the library is functional, as in it can load and render glyphs. These can be made more robust at a later date, but for simplicity I opted to not add too many just yet.
Rework library loading
I've added a static constructor to the internal FreeType API class to set up a new DLL import resolver. This allows us to load the correct library name on Linux. It will try to load the existing
freetype6.so/dllfirst, then try to loadlibfreetype.so.6.This makes it so the system library is a fallback; it will try to load
freetype6.sofirst, then try the system library. This makes it so if the user was already able to loadfreetype6, there are no changes. If not, they will use the system version which closes #1.There's also a path for Mac but I don't have natives for Mac.
Tested Platforms