Repository navigation
Debug Console v3.0.0-alpha-010-wip
Pre-releaseThoughts at this stage:-
I am removing Mac builds for now as we can only sensibly build for arm64 with the tools to hand.
- To build universal2 binaries looks like a very deep rabbit hole. Pip is not very friendly about cross-platform, the github standard python builds are not universal2 either, so getting it going is not trivial. That's a shame, as pyinstaller can make a universal2 appimage, which would be "more Mac".
- It may be possible to make environments for both arch's on an arm64 mac and then strap the results together, sign them etc. But again, a deep rabbit hole.
- I feel it will be better/faster/simpler to write a tool/script to use pyenv and venv or the native python (if >=3.6) and venv to do the job. It should work the same on both architectures.
So... it looks like the Mac version will come in kit form. It may be quite easy to make it a click-and-run bundle for recent versions of macos.
For arm32/64 linux, and in fact any other architecture, the source should be relatively easy to run. I'd prefer a trend toward bundling simple-ish tools to self-install "as source" on recent platforms that are python friendly. The same instructions can be adapted to use pyenv/venv on rustic distributions. Only Windows truly warrants compilation for standalone use.
A small suite of bash/python scripts or one-liners in a help file might need to be conjured to simplify deployment and use by the less python-savvy.
The windows version currently spawns a console for stdout/stderr, allowing the output of --help to be seen, and errors. I need to 'knit in' stdout/stderr to log before turning off that console. If there's a way to detect the absence of console output it wouldn't be too hard to make --help|-h (and invalid args) spawn an 'about' style popup window of help text.
Should there be desire to bundle this with the dev/test branches of the game on x86_64 Win/Lin, it would be appropriate to use compiled binaries to dispense with dependencies. For all other cases (save perhaps Windows), I'd suggest install "as source" is superior. Under Linux, with the use of .desktop and icon files, the differences between source and binary installations are indistinguishable to the user, apart from the source version starting faster.
By default, all configs and logs are written on all platforms in $HOME/.OoDC/
I need to write up some basic requirements, at least for Linux.