Arm64 Support

[ds5678]

What would be involved in setting up continuous integration for Arm64 binaries?

[btzy]

I'm not against this, but I'm not sure how difficult this would be. Currently, this project only uses GitHub hosted runners, which I think are running x86-64 (?), and I am not sure whether they have any Arm64 runners available. There used to be a CircleCI runner as well before GitHub runners had support for macOS 12, so it is possible if CircleCI has the Arm64 runners you want.

Is there anything you're specifically looking to test with an Arm64 binary? Since this library doesn't really mess around with bit widths and architecture-dependent things, I don't see any reason that might make it not compile on Arm64.

[ds5678]

I am unfamiliar with the C++ build process. In C#, it does not depend on the server cpu architecture and is as simple as dotnet build -r osx-arm64.

[btzy]

This answer suggests that we can set something on CMake to cross compile for arm64. However, I'm not sure why you want it in the CI. The CI is meant for testing that PRs don't break the build, and since we don't have any architecture-specific code, there shouldn't be any reason for this library not to work on arm64.

[ds5678]

Is there a reason I shouldn't use binaries from continuous integration in a NuGet package?

[btzy]

Hmm your question got me thinking.

I don't think there is any reason why in principle you shouldn't use binaries from CI in a package, but I think in practice most CI binaries are meant for testing purposes and so they may be build with assertions and other options that aren't ideal for a release. The CI config is also IMO not considered a 'stable' part of the project, unless otherwise stated - if I wanted to stop using GitHub Actions tomorrow and move to CircleCI, that shouldn't necessitate any version bump.

For the case of this project, I happen to already be building in release mode in the CI, so it is okay to just use the binaries. However, there is no guarantee that CI will continue to build the project in release mode, if, say, I find that we can catch more bugs by changing the mode.

Essentially, the purpose of continuous integration is to check for code correctness of incoming pull requests, rather than to make a release. I suppose what you are looking for might be called continuous deployment (CD), but this seems rarely used for libraries.

[btzy]

In any case, if you're supporting Windows 10 too, you'll also want x86 32-bit packages, so you'll need to get an x86 32-bit version of the nfd library.

[ds5678]

Unfortunately, I was only able to compile Arm64 builds for Windows. Cross-compilation was rejected on Mac and Ubuntu.

https://github.com/AssetRipper/nativefiledialog-extended-builds

[btzy]

Hmm, I see that the build succeeds in the repo you linked above - did you fix it?

I don't know much about NuGet, are you intending to also build binary packages for Mac and Ubuntu? I was under the impression that "regular" C# and .NET only worked on Windows, and you had to install Mono to run C# on Mac and Linux.

[ds5678]

.NET Framework (the legacy .NET) is Windows-Only.

.NET Core is cross platform

[ds5678]

As I said above, I ran into issues with cross-compilation being unsupported when I attempted to build on Mac and Ubuntu.

I'm not giving up, but getting Arm64 support is not a priority for me at the moment.