A "category" (or "module") is now displayed with each log message
together with the source function. The name of the category is derived
from the source file name (see modname() in log.c).
Taisei now also loads a "logfilter" file from the storage directory that
controls which messages are propagated to the console. You can filter by
log level, category, and function. Simple glob pattern matching is
supported. Each line contains a new rule; empty lines and lines starting
with # are ignored. Rules are processed from top to bottom.
Example logfilter file:
# [mask] [category] [function]
# Hide debug messages by default:
-d * *
# Show debug messages from all of the rendering-related modules:
+d renderer/* *
# Also show debug messages from my specific function:
+d * my_function
# Hide info about resource loading/unloading:
-i resource unload_resource
-i resource load_resource_finish
# Suppress everything from a specific module:
-a spam *
Note that only the console output is filtered; the log file still
contains all messages. In addition to that, the log file now also
contains the filename and line number of the original log call with
every message.
The output of __FILE__ previously depended on where the build directory
is and was needlessly verbose. With this change, all filenames are
relative to the src/ directory.
Logging of source file names is now also enabled for release builds
(although this is not used yet).
This shouldn't be needed, as according to the Linux inotify(7) man page,
the entries are supposed to be aligned. It looks like libinotify-kqueue
doesn't respect this and doesn't properly zero-pad the name field.
This function is meant to flush any internal buffers and (hopefully)
ensure the data has reached its ultimate destination (e.g. a file on
disk) before returning. This is currently implemented as a crude hack
and only supports stdio-based RWops. It calls fflush() on the internal
FILE* pointer, and on POSIX-systems it also calls fsync() on the file
descriptor.
It's now based on directory monitoring, which is more complicated, but
also much more reliable, especially when dealing with move events and
hard links. It is also closer to the semantics we actually want
(monitoring fs paths for changes, not inodes). It will still get
confused if the directory itself gets moved (directly or indirectly),
though, but handling that correctly is absurdly difficult and not
important for our use-case.
Importantly, FileWatch no longer becomes useless after reporting a
FILEWATCH_FILE_DELETED event: if another file is placed onto the same
path later, the FileWatch will report FILEWATCH_FILE_UPDATED. Some
client logic can be simplified because of that.
* add Dockerfiles, Makefile, and .dockerignore
* move makefile to other branch, add new pip lib
* Dockerfile work
* stashing changes, but Windows ANGLE build is almost working
* actually compiles ANGLE
* fix one typo
* more refactoring
* more 'fixes'
* deck chairs on the titanic
* it absolutely must be Visual Studio and not Build Tools because Google
* moar space
* this ACTUALLY builds ANGLE in a container, yay
* stashing makefile changes
* move dockerfile directories, port over changes from fork
* cleanup
* change filename
* pre-emptive PR changes, move to misc/ci/
* use proper build args
* Dockerfile for building Switch tools for GHA
* less deps for switch dockerfile
* windows dockerfile improvement
* clean up Dockerfiles, move Docker-specific Makefile to /misc/ci
* make this actually work
* add gnupg
* bump switch/debian version in dockerfile
* package name change for Switch dockerfile
* update and remove cursed ANGLE build (we have GHA for that now)
* remove last of ANGLE build nightmare
* new Windows build image file
