MirrorHub
/
construct
mirror of https://github.com/matrix-construct/construct
0
0
Fork 0
Code Issues Releases Wiki Activity

ircd: Update stale README information. [ci skip]

This commit is contained in:
Jason Volk 2019-10-05 16:18:09 -07:00
parent 1980fd5e73
commit b5b4f9b4a5
2 changed files with 12 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
ircd/README.md
View File

@ -1,6 +1,6 @@
# IRCd Library Definitions
# Library Definitions
This directory contains definitions and linkage for `libircd`
This directory contains definitions for `libircd`
The purpose of `libircd` is to facilitate the execution of a server which
handles requests from end-users. The library hosts a set of pluggable modules
@ -26,8 +26,8 @@ header or third-party dependency which is not involved in the
[ircd.h include group](../include/ircd#what-to-include). Second to that, units
tend to be divided by namespace and the subsystem they're implementing. Units
can further be divided if they become unwieldy, but we bias toward large aggregate
units. Within these large units, there are divisions which group the definitions
by the `include/ircd/` header which declares them.
units in this library. Within these large units, there are divisions which group
the definitions by the `include/ircd/` header which declares them.
We do not included third-party headers in our own [headers](../include/ircd)
which are included by others. A developer of an `ircd::` interface can choose

34
modules/README.md
View File

@ -1,30 +1,17 @@
# IRCd Module Tree
# Module Tree
This directory contains dynamically loadable functionality to libircd. Many of
these modules provide essential application functionality, but are not always
required to be directly linked and loaded into libircd proper. Most application-
specific functionality (i.e "business logic") is contained in modules within this
tree.
This directory contains dynamically loadable functionality to libircd.
#### Layout
The `modules/` directory tree is primarily shaped the same as the HTTP resource
tree in which most of its modules register themselves in.
Note that the installation layout is not the same as the development source
layout (i.e in git). Upon installation, the module tree is collapsed into a
single directory and installed into
`$prefix/lib/modules/construct/$directory_$module.so`; where directories are
replaced by underscores in the final `SONAME`. this may be subject to
improvement.
#### Approach
Unlike most of the module systems found in traditional free software projects,
our approach is oriented around *global symbol* availability to the address
space rather than explicit imports from self-contained modules. This direction
is made viable by C++ and advances in the compiler and linker toolchains. The
result is significantly simpler and more convenient for developers to work with.
Unlike most of the module systems found in traditional C free software
projects, our approach is oriented around *global symbol* availability to the
address space rather than explicit imports from self-contained modules. This
direction is made viable by C++ and advances in the compiler and linker
toolchains. The result is significantly simpler and more convenient for
developers to work with.
- Modules are loaded with `RTLD_GLOBAL` on both posix and windows platforms.
Use of C++ namespaces, visibility attributes, `STB_GNU_UNIQUE`, etc are
@ -68,8 +55,3 @@ Makefile.am.
3. Add the module `.la` name to the appropriate LTLIBRARIES list
in Makefile.am.
4. At this time, most modules are listed explicitly in `ircd/m.cc` to
provide a strict load and unload ordering based on dependency. Note that
if the module is not `m::` related there may be similar lists for other
subsystems.