* librb is no longer a separately configured subproject.
* charybdis is now a standalone directory with a binary.
* Include path layout now requires a directory ircd/ rb/ etc.
This version leverages a flexible, cleaner key-value strategy
reducing the need to design entire new headers for every feature
addition, change, etc.
* A friendly declaration for the module authors, with minimal
requirements to fill in, and explicit labels of what the fields are.
* Repetition of keys, removing references to (and the requirement to
build) a clist, hlist and hfnlist and caplist and whatever the future
holds.
* Safe deterministic loading and unloading. Keys are evaluated in
order, errors can be recognized, and unloading occurs in reverse
order.
ircd: Refactor internal half of modules.c, with some V3 additions.
Provides better delegation for versions, a cleaner stack with better
error handling, and some functionality deduping. V1 and V2 handlers
are still somewhat unaltered, just factored in.
This will allow service process monitoring to recognise the difference
between a shutdown and an error of a -foreground ircd, because only
/DIE (or SIGINT) will exit with return code 0.
There's no reason to really have these in the main ircd anymore, static
modules are dead and aren't coming back.
To ensure people don't do something hopelessly retarded, this is a core
module.
.la archives are prohibited by most Linux distributions because they
clutter up the linker. They may get caught up as victims in scripts that
purge .la files. Besides, .la files don't matter for simple loadable
modules on most systems.
So, what we do now instead is just use the platform suffix detected by
libtool.
Also fix up some return values and stuff to use bool (or void if
nothing). I just did it whilst I was here.
According to jilles, the return value used to signify whether or not the
client had exited. This was error-prone and was fixed a long, long time
ago, but the return value was left int for historical reasons.
Since the return type is not used (and has no clear use case anyway),
it's safe to just get rid of it.
MAPI V1 is still supported for legacy modules, but it is highly
recommended to update to MAPI V2. It includes support for capability
tables, module descriptions, and implicit versions.
