Aroma will have the concepts of "modules" will can exports functions like system rpls do. There will be a module for logging and this PR is implementing support for it.
Advantages of outsourcing the actual logging implementation into a module:
Can be updated/replaced without recompiling every homebrew
In combination of a plugin it would be even possible to have some runtime implementation
This avoids that every homebrew/module/plugins will need to bring they own logging implementation (e.g. via udp), which reduces filesizes. (simple modules which used WHBLogUdpInit() are now 5KiB instead of 45KiB)
Recommended usage:
Currently Aroma is not release and there are use cases where Aroma (and so also the LoggingModule) is simply not available. If this a possible scenario for the homebrew its recommened to fallback into another logging method like this:
if(!WHBLogModuleInit()){
// If the logging module is not avaible use something different
// e.g. WHBLogUdpInit(); or WHBLogCafeInit();
}
This PR also includes a fix for the WHBAddLogHandler to return TRUE if you try to add a loghandler which was already added before to allows this fallback behaviour.
Aroma will have the concepts of "modules" will can exports functions like system rpls do. There will be a module for logging and this PR is implementing support for it.
Advantages of outsourcing the actual logging implementation into a module:
WHBLogUdpInit()
are now 5KiB instead of 45KiB)Recommended usage: Currently Aroma is not release and there are use cases where Aroma (and so also the LoggingModule) is simply not available. If this a possible scenario for the homebrew its recommened to fallback into another logging method like this:
This PR also includes a fix for the
WHBAddLogHandler
to return TRUE if you try to add a loghandler which was already added before to allows this fallback behaviour.