Automatically release portable builds about shiromino

7d2195d should take care of Windows.

[nightmareci]

I've made changes that change how the build is done for portable builds, adding a CMake PORTABLE boolean configuration option that forces the search directories to only the executable/Mac app's directory. SDL 2 provides a built-in function for getting the "base path", SDL_GetBasePath(), which is the executable's directory for Windows, macOS, and Linux (and presumably other "desktop" platforms, like BSDs), and is now used instead of the previous platform-specific solutions. The GitHub actions should be changed to use the PORTABLE option, and build the portable packages, as the portable packages are entirely created with CMake and CPack, via commands like:

# "Unix" platforms, only macOS for now.
# There are additional options required for later outside-CMake notarization to work properly, this is just a minimal example of how to do it.
cmake -B build-portable -S . -DCMAKE_BUILD_TYPE=Release -DPORTABLE=True
cmake --build build-portable --target package

# Windows MSVC only.
# <architecture> can be Win32 (32-bit x86),
# x64 (64-bit x86),
# ARM (32-bit ARM; Windows is available for 32-bit ARM, but Microsoft doesn't officially support it),
# and ARM64 (64-bit ARM; Microsoft officially supports this, this is the true "Windows for ARM" platform).
# Windows builds are single-architecture-only, the Windows executable format doesn't have a trivial "Universal Binary" solution like macOS.
cmake -B build-portable -S . -DPORTABLE=True -A <architecture>
cmake --build build-portable --config Release --target package

# More complete scripts for portable build generation are in packages/<platform>-portable/build*, I created those for running on my local machines.

Windows packages must be generated with Visual Studio/MSVC for the CMake automated library bundling to work (the CMake 3.16 feature to do that doesn't support MinGW). In some recent efforts I've made on the code, it seems the code is working entirely fine with MSVC now, and that bit about std::filesystem::path not having the string conversion operator is actually a mistaken interpretation of how the C++ standard specifies conversion of path objects; to guarantee conversion to a UTF-8-encoded string you should directly use the std::filesystem::path::string() method on all platforms, the standard actually specifies the default string conversion operator produces a native-encoding string, which is the desired UTF-8-encoded string on Unix platforms, but UTF-16 on Windows.

macOS packages should be generated with Universal Binary libraries supporting x86_64 and arm64; Homebrew is native-architecture-only, so it's not suitable for creating portable packages, but MacPorts can provide Universal Binary libraries, and I've found it works fine in some preliminary testing on both my M1 Mac Mini and other people's Intel Macs. And the macOS package has to be notarized before it can be distributed, so the "Apple did not find malware..." message is shown when a user starts the game for the first time; I'm unsure of how to do that properly in GitHub actions, but I do have Apple developer enrollment, so at present I can notarize software on my own local machine.

For Linux portable builds, the two options I can think of at present are either a bare command-line binary with a directory of bundled libraries, using the $ORIGIN Linux library linking functionality to direct the binary to use them, or AppImage. I think AppImage would be preferable, but I've not investigated how to properly get the directory of the opened AppImage itself, not the directory of the actual Linux executable in the AppImage-created virtual filesystem; while bundling all assets into the AppImage package itself would work fine, it doesn't allow users to customize assets without building the package themselves, so I'd prefer the portable Linux package have the assets external to the AppImage executable file. And, regardless of the method used for Linux builds, the builds must be generated to link against older C/C++ standard libraries, such as by building with an older still-supported Ubuntu LTS version, which might require manually installing the official Kitware-provided CMake Ubuntu repository/package for a newer CMake; more recent SDL packages which can be provided by some Ubuntu PPAs are either required, or at least preferable for picking up improvements and bug fixes.