Successfully building the app requires the followings to be installed:
- Haxe 4.3.7 (updated from 4.2.5)
- Neko VM 2.4.1 (for Neko builds) - Haxe installer will install Neko VM as well
Required and properly pre-configured Haxelibs:
- HXCPP v4.3.89 - for Native/C++ builds
- Lime 8.2.2 - A foundational layer for OpenFL that handles low-level operations
- OpenFL 9.4.1 - A powerful framework for building cross-platform applications
- FeathersUI - UI component library for Haxe and OpenFL
- Actuate - Animation library for Haxe (installed with FeathersUI)
- Champaign - Library for building cross-platform applications
- MXHX-Component - Library for creating UI components using MXHX
- MXHX-FeathersUI - Integration between MXHX and FeathersUI
- YAML - Library for parsing and generating YAML data
- Format - Library for various file format support
- HXP - Project scripting library
Windows-specific libraries:
- Flixel - 2D game engine used for specific Windows functionality
- hxWindowColorMode - Library for handling window color modes on Windows
C++ Compilers
- In order to successfully compile the app for native targets, a C++ compiler is required to be installed and configured. Please read the relevant part of the Haxe manual regarding the recommmended and supported C++ compilers.
Additional software required to run the app
To build the app for macOS (x86-64 native/C++), make sure you're in the root directory of the project and enter the followings in command line:
openfl build mac
or for debug builds
openfl build mac -debug
Note: Building the app on arm64 architecture (namely Apple M1/M2 (Silicon) SOCs) is currently not possible. Neither HXCPP nor Lime works currently on arm64 natively. The x86-64 compilers and the toolchain, however, can be installed and configured if Rosetta is already installed, so the app can be built and launched if Rosetta is present.
To build the app for Windows (native/C++), make sure you're in the root directory of the project and enter the followings in command line:
openfl build windows
or for debug builds
openfl build windows -debug
To build the app for Linux (native/C++), make sure you're in the root directory of the project and enter the followings in command line:
openfl build linux
or for debug builds
openfl build linux -debug
Neko build target is recommended for a quick local build, test, and deployment. The functionality and feature-set of the Neko build is equivalent of the Native/C++ build's.
To build the app for Neko, make sure you're in the root directory of the project and enter the followings in command line:
openfl build neko
or for debug builds
openfl build neko -debug
The generated app will be bundled with the necessary libraries and executables on all supported platforms.
For quick build-and-run enter openfl test neko or openfl test neko -debug in the command line.
Builds the app with debug info. Enables debug and verbose log levels.
Forces colorized console output.
Forces machine-readable logging. Please read below for details
Forces verbose log level, works only if -debug is also defined.
Important! Enabling verbose logging is strictly for development purposes. Enabling it may lead to potential memory leaks, app misbehaviors, errors, crashes, and may expose some (although not necessarily overly sensitive) user data. Please make sure it's not defined in public builds! Please read below for more information
The app is being built with net.prominic.genesis.superhumaninstaller package id by default. If you want to change that without modifying project.xml, define your custom package id in the command line, e.g.
openfl build mac -Dpackageid=com.myorganization.superhuman
Builds the app with final release configuration (disables debug info, debug and verbose logging, machine-readable output). Works only if -debug is omitted. Final release configurations are intended to build the public version of the app.
If the compilation succeeds, the production app bundle will be placed in ./Export/Production/{platform}/bin, the debug (development) builds in ./Export/Development/{platform}/bin directory.
macOS note: Building and running the app bundle the first time on an external volume, the OS shows a dialog in which the user has to grant access to Removable Volumes for the app, which permission is neccessary for accessing the bundled assets. If the access is denied, the app might run into errors. If you accidentally clicked "Don't allow", open macOS Settings, select "Security & Privacy", click "Privacy" tab, select "Files and Folders" in the list on the left, and grant access to SuperHumanInstaller in the list on the right (by making sure of "Removable Volumes" checkbox is selected).
The app can be launched with the following optional command line parameters:
--colorEnable internally styled (colorized) console output. Useful to visually distinguish different level of messages. Messages printed to stderr are never styled.--loglevel={level}Define default logging level. Available values (in hierarchical order from bottom to top):noneor0Disable logging.fatalor1Only fatal error messages will be printed and logged.erroror2Error messages (and below) will be printed and logged.warningor3Warnings (and below) will be printed and logged.infoor4Informational messages (and below) will be printed and logged. This is the default value.debugor5Debug messages (and below) will be printed and logged. Debug messages contain additional useful information for debugging. Can only be set if the app is built with-debugcompiler parameter, otherwise it defaults toinfo.verboseor6Only available if the app is built with-debugcompiler parameter, otherwise it defaults toinfo. Warning: it WILL print a lot of messages, most of them are only meaningful to the developers who are working on the app! (E.g. it might forward internally spawned native processes' stdout/stderr to its own stdout/stderr) It's highly discouraged to make this option available in public builds! Please read more above-
Notes on logging: All messages will be printed to stdout and a text file in
{applicationStorageDirectory}/log.txt, errors and fatal errors/exceptions will be printed to stderr as well. Currently the app (the main process) only exits if a fatal error/exception occurs.
--mrGenerate machine-readable output (JSON formatted data). Machine-readable output always contains the message, the time-stamp (the most precise system time available in seconds (Float)), the level of the message (as Int), and an optional source file path and line number if the app is compiled with-debug. Useful if a (parent) process is intended to catch and parse stdout/stderr. Each line should be parsed separately as JSON objects. Machine-readable output is never styled.- Example of an informational machine-readable log entry in debug build:
{"time":1670321372.27593,"level":4,"message":"Initializing Super.Human.Installer v0.1.0...","source":"Genesis/Source/genesis/application/GenesisApplication.hx:118"}
- Example of an informational machine-readable log entry in debug build:
--notimestampDisable time-stamps in logs (has no effect on machine-readable output)--prunePrune invalid Vagrant machines on app start
Example of a command line launch with parameters:
SuperHumanInstaller.exe --loglevel=warning --mr
-
SuperHumanInstaller [macOS]:
/Users/$USER/Library/Application Support/SuperHumanInstaller -
SuperHumanInstaller [Windows]:
%AppData%\SuperHumanInstaller -
SuperHumanInstallerDev [macOS]:
/Users/$USER/Library/Application Support/SuperHumanInstallerDev -
SuperHumanInstallerDev [Windows]:
%AppData%\SuperHumanInstallerDev