* Update log android to match the current issue template
* Fix GUI gdb frontends getting wrecked by the older glib library we ship w/
KOReader
* Slightly more aggressive valgrind defaults
It's slower, but interpreting results without leak-check=full ends up
costing more time than just running with it.
* Add a callgrind shortcut
* Use getopt instead of a hand-rolled hack for option parsing
* Make it clearer that complex args should be quoted
* Document prompt
* Add a Valgrind suppression file for libdrm/mesa on AMD hardware
Because mesa/libdrm isn't built w/ -D valgrind=enabled on Gentoo,
and Valgrind is very much not happy with mesa ;p.
* Allow toggling reader.lua's sane return mode
(Enabled automatically under gdb/valgrind).
Should hopefully weed out some noise from valgrind reports.
* Propagate reader.lua's return code
* Sim a few other common devices
* Handle assigning values to short options with an equal instead of a space, like the previous solution
(This is purely for backward compatibility purposes, this is a syntax that'd fail with the C getopt, too).
* Add gnu-getopt to the build requirement on macOS, because of course everything is terrible.
* Steer people more strongly towards koxtoolchain
And stop mentioning blatantly broken/outdated stuff
* Add macOS to the list
Also, put 'em in hierarchical order, and link to the main build docs for
the native emulator.
* Update macOS PATH shenanigans.
c.f., https://github.com/koreader/koreader-base/pull/1052
* Prefer coreutils, it now ships everything we need.
(Or it always did? I apparently don't actually have coreutils
installed on my end).
* Also recommend putting Homebrew first in PATH
Mainly because it turns out that's how I tested this the last time ;).
Also, it just makes sense, and might be part of Homebrew's
recommendations anyway.
* Made Porting not so hilariously outdated.
* Minor tweaks to the macOS build instructions and the various quirks involved in getting it to behave (and accompanying actual build fixes).
This commit standardizes the various todos around the code a bit in a manner recognized by LDoc.
Besides drawing more attention by being displayed in the developer docs, they're also extractable with LDoc on the command line:
```sh
ldoc --tags todo,fixme *.lua
```
However, whether that particular usage offers any advantage over other search tools is questionable at best.
* and some random beautification
