2016-07-20 20:55:46 +02:00
|
|
|
AM_CPPFLAGS = \
|
|
|
|
|
-I$(top_srcdir)/include \
|
2016-10-16 04:09:38 +02:00
|
|
|
@JS_CPPFLAGS@ \
|
2016-08-15 04:44:16 +02:00
|
|
|
@BOOST_CPPFLAGS@ \
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
-include $(top_srcdir)/include/ircd/ircd.h \
|
2016-11-29 16:23:38 +01:00
|
|
|
-include $(top_srcdir)/include/ircd/mapi.h
|
2016-07-25 08:50:26 +02:00
|
|
|
|
2016-07-20 20:55:46 +02:00
|
|
|
AM_LDFLAGS = \
|
|
|
|
|
-L$(top_srcdir)/ircd \
|
2016-11-08 01:28:12 +01:00
|
|
|
@JS_LDFLAGS@ \
|
2016-07-20 20:55:46 +02:00
|
|
|
@BOOST_LDFLAGS@
|
|
|
|
|
|
|
|
|
|
AM_LDFLAGS += \
|
|
|
|
|
-avoid-version \
|
2016-11-08 01:28:12 +01:00
|
|
|
-module \
|
|
|
|
|
-Wl,-fuse-ld=gold \
|
|
|
|
|
-Wl,--shared \
|
|
|
|
|
-Wl,--export-dynamic \
|
2017-03-31 00:58:36 +02:00
|
|
|
-Wl,--no-gnu-unique \
|
|
|
|
|
-Wl,--no-allow-shlib-undefined
|
|
|
|
|
# -Wl,--no-undefined
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
# -export-symbols-regex IRCD_MODULE*
|
|
|
|
|
# -export-symbols-regex *
|
2016-07-20 20:55:46 +02:00
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
# This puts the source in client/ but the installed
|
|
|
|
|
# library is client_X.so in the main modules dir.
|
|
|
|
|
client_moduledir=@moduledir@
|
|
|
|
|
client_client_versions_la_SOURCES = client/versions.cc
|
|
|
|
|
client_client_register_la_SOURCES = client/register.cc
|
2017-03-11 04:31:20 +01:00
|
|
|
client_client_login_la_SOURCES = client/login.cc
|
2016-11-29 16:23:38 +01:00
|
|
|
client_module_LTLIBRARIES = \
|
|
|
|
|
client/client_versions.la \
|
2017-03-11 04:31:20 +01:00
|
|
|
client/client_register.la \
|
|
|
|
|
client/client_login.la
|
2016-11-03 01:55:30 +01:00
|
|
|
|
2016-09-06 01:10:30 +02:00
|
|
|
moduledir=@moduledir@
|
2016-09-10 23:58:50 +02:00
|
|
|
module_LTLIBRARIES = \
|
