Investigate Action to build native Platform libs

[NoelFB]

Right now I manually build the native Platform libs for Linux/Windows (and in theory MacOS but so far I have not), and then they're included in the repo directly. I like having them in the repo because it doesn't require downloading, building, or copying library files around when someone freshly clones the project.

However, this does mean that occasionally the compiled libraries are outdated depending on which platforms I happen to rebuild. Ideally there would be some way to automatically rebuild the native Platform libs for Linux/Windows/Mac whenever they actually change. The downside is that it feels like you could end up with double-commits for any changes (ex. commit changes to native API, action runs and rebuilds libs and then commits those?).

So I'm not sure if there's a suitable answer that both 1) keeps the libraries inside the repo for ease-of-use and 2) doesn't get overly complicated with lots of double-commits and stuff.

[MrBrixican]

To my knowledge, there isn't much that could be done to avoid double commits without accidentally causing issues for those syncing with master.

Two options (each with their own cons) I could see:

• Manual action which you can kick off to build and replace the platform libs
  • Will still have commit messages, but will save you the effort of having to do it manually
  • Ensures consistent build environment
  • This could be an automatic action that would only kick off based on path filter. So it wouldn't be every commit.
• Two parts: Add prebuild event to the Foster.Framework csproj that builds the lib (for the current system) via cmake, and then add lib builds to your NuGet release action (again through cmake)
  • Will require the user to have the ability to use cmake and any other build dependency
  • Ensures consistent build environments for NuGet packages

Also worth noting is that GitHub actions doesn't have Apple Silicon support yet, so no GitHub Action will build libs for that, unless you use a self hosted runner.

[NoelFB]

I think I like the first option a lot more, and to just use a path filter so it only rebuilds them if changes to the native C files were pushed. I really want to avoid any end-user requirements (for major platforms) because I don't feel like most people writing C# want to have to deal with CMake or C/C++ tooling. If they want to build it for a different platform (or Apple Silicon until that's supported) then I'm OK with the requirement of having to build the native lib yourself.

I would need to look into how to actually do that. I'm not super familiar with Github Actions, but I see it basically needing to:

• use a path filter on Platform/src/* and Platform/include/*
• build native libraries for Linux / Windows / Mac, into the correct folders (lib64, x64, and osx respectively)
• commit those new files to the repo (hopefully in a single commit and not one-per-platform?)

[NoelFB]

This seems to be in a good working state! Can re-open if other issues arise, or if we want to add more platforms (and eventually Apple Silicon if Github ever supports that)