* First attempt at automating macOS builds
* Added Qt5 path
* I am retarded
* Yet another attempt
* Now builds a bundle succesfully
* Fixed artifact upload, I hope
* god damn it we really need to set up caching later
* Add packages cache
* Use home for homebrew cache
* Add extra CMake flags
* Move to 10.9 as minimum version
* Fix bundle problem
* Make option -l doesn't do anything alone
* Update actions
* Added chmod +x so the resulting executable is runnable without user's actions
* fixed path to Linux executable
* tf is wrong with me
* where the hell is our working directory and why can't I access multimc from cwd
* i can't fucking take it anymore
* maybe this time the path is right
* Remove some unneeded packages
* Install only Qt since is only one required
* Escape CMake commands
* Build Qt5.6
* Move to different steps
* Fix directory
* Remove codecs flag
* Use dmg file
* Fix directory
* We can't get Qt5.6 in macOS
Co-authored-by: Sebastían <sebastianmontoya209@gmail.com>
It appears that Minecraft Forge for Minecraft 1.17 will require setting
JVM arguments to operate, this is not currently possible with MultiMC's
meta.
Therefore, when Forge for 1.17 is released a solution will need to be
looked into.
Here lies yet another early-stage move to debrand the MultiMC codebase,
as well as reducing the burden of updating strings across the codebase
for a future MultiMC6.
macOS seems to dislike changing files in the APPBUNDLE.app/Contents directory because it has to re-scan the directory every launch. As a result, large amounts of data there seems to cause freezes of MultiMC. Moving the default location outside of this directory, and thus the data, stops these freezes.
There is also a dialogue when the user first opens the app that asks them if they'd like to migrate their data folder, if they select yes it will move it, and if they select no it will not move it and allow them to move it later with an option in settings.
