2007-01-25 07:40:21 +01:00
|
|
|
/*
|
|
|
|
* ircd-ratbox: A slightly useful ircd.
|
|
|
|
* modules.c: A module loader.
|
|
|
|
*
|
|
|
|
* Copyright (C) 1990 Jarkko Oikarinen and University of Oulu, Co Center
|
|
|
|
* Copyright (C) 1996-2002 Hybrid Development Team
|
|
|
|
* Copyright (C) 2002-2005 ircd-ratbox development team
|
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
|
|
|
* Copyright (C) 2016 Charybdis Development Team
|
|
|
|
* Copyright (C) 2016 Jason Volk <jason@zemos.net>
|
2007-01-25 07:40:21 +01:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
|
|
|
|
* USA
|
|
|
|
*/
|
|
|
|
|
2017-08-29 02:05:05 +02:00
|
|
|
#include <cxxabi.h>
|
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 <boost/filesystem.hpp>
|
|
|
|
#include <boost/dll.hpp>
|
|
|
|
|
|
|
|
namespace filesystem = boost::filesystem;
|
|
|
|
namespace load_mode = boost::dll::load_mode;
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
#include <ircd/mapi.h> // Module's internal API
|
2016-01-06 04:39:09 +01:00
|
|
|
|
2016-08-13 05:05:54 +02:00
|
|
|
namespace ircd {
|
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
|
|
|
namespace mods {
|
2016-08-13 05:05:54 +02:00
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
struct mod
|
|
|
|
:std::enable_shared_from_this<mod>
|
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
|
|
|
{
|
2017-03-31 00:54:17 +02:00
|
|
|
static std::stack<mod *> loading; // State of current dlopen() recursion.
|
2016-11-29 16:23:38 +01:00
|
|
|
static std::map<std::string, mod *> loaded;
|
|
|
|
|
2017-03-31 00:54:17 +02:00
|
|
|
filesystem::path path;
|
|
|
|
load_mode::type mode;
|
2017-04-03 07:59:30 +02:00
|
|
|
std::deque<mod *> children;
|
2016-11-29 16:23:38 +01:00
|
|
|
boost::dll::shared_library handle;
|
|
|
|
mapi::header *header;
|
|
|
|
|
|
|
|
// Metadata
|
|
|
|
auto &operator[](const std::string &s) const { return header->meta.operator[](s); }
|
|
|
|
auto &operator[](const std::string &s) { return header->meta.operator[](s); }
|
|
|
|
|
|
|
|
auto name() const { return handle.location().filename().string(); }
|
|
|
|
auto location() const { return handle.location().string(); }
|
|
|
|
auto &version() const { return header->version; }
|
|
|
|
auto &description() const { return (*this)["description"]; }
|
|
|
|
|
|
|
|
bool has(const std::string &name) const;
|
|
|
|
template<class T> const T &get(const std::string &name) const;
|
|
|
|
template<class T> T &get(const std::string &name);
|
|
|
|
template<class T = uint8_t> const T *ptr(const std::string &name) const;
|
|
|
|
template<class T = uint8_t> T *ptr(const std::string &name);
|
|
|
|
|
2017-04-03 07:59:30 +02:00
|
|
|
bool unload();
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
mod(const filesystem::path &,
|
|
|
|
const load_mode::type & = load_mode::rtld_local | load_mode::rtld_now);
|
|
|
|
|
|
|
|
~mod() noexcept;
|
2007-01-25 07:40:21 +01:00
|
|
|
};
|
|
|
|
|
2017-08-16 22:15:14 +02:00
|
|
|
static const auto suffix
|
|
|
|
{
|
|
|
|
boost::dll::shared_library::suffix()
|
|
|
|
};
|
|
|
|
|
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
|
|
|
filesystem::path prefix_if_relative(const filesystem::path &path);
|
2016-09-05 23:27:35 +02:00
|
|
|
filesystem::path postfixed(const filesystem::path &path);
|
2017-08-16 22:15:14 +02:00
|
|
|
filesystem::path unpostfixed(const filesystem::path &path);
|
2016-09-05 23:27:35 +02:00
|
|
|
std::string postfixed(const std::string &name);
|
2017-08-16 22:15:14 +02:00
|
|
|
std::string unpostfixed(const std::string &name);
|
2016-09-05 23:27:35 +02:00
|
|
|
|
2016-10-26 08:16:33 +02:00
|
|
|
template<class R, class F> R info(const filesystem::path &, F&& closure);
|
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
|
|
|
std::vector<std::string> sections(const filesystem::path &path);
|
|
|
|
std::vector<std::string> symbols(const filesystem::path &path);
|
|
|
|
std::vector<std::string> symbols(const filesystem::path &path, const std::string §ion);
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
// Get the full path of a [valid] available module by name
|
|
|
|
filesystem::path fullpath(const std::string &name);
|
|
|
|
|
|
|
|
// Checks if loadable module containing a mapi header (does not verify the magic)
|
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
|
|
|
bool is_module(const filesystem::path &);
|
|
|
|
bool is_module(const filesystem::path &, std::string &why);
|
|
|
|
bool is_module(const filesystem::path &, std::nothrow_t);
|
2016-11-16 03:41:12 +01:00
|
|
|
bool is_module(const std::string &fullpath, std::string &why);
|
|
|
|
bool is_module(const std::string &fullpath, std::nothrow_t);
|
|
|
|
bool is_module(const std::string &fullpath);
|
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
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
struct log::log log
|
|
|
|
{
|
|
|
|
"modules", 'M'
|
|
|
|
};
|
|
|
|
|
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
|
|
|
} // namespace mods
|
|
|
|
} // namespace ircd
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2016-11-29 16:23:38 +01:00
|
|
|
// module
|
2016-11-16 03:41:12 +01:00
|
|
|
//
|
2016-09-10 01:14:29 +02:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
ircd::mods::module::module(const std::string &name)
|
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
|
|
|
try
|
2016-11-16 03:41:12 +01:00
|
|
|
:std::shared_ptr<mod>{[&name]
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
const auto path(fullpath(name));
|
|
|
|
const auto filename(postfixed(name));
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
// Search for loaded module and increment the reference counter for this handle if loaded.
|
|
|
|
auto it(mod::loaded.find(filename));
|
|
|
|
if(it != end(mod::loaded))
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
auto &mod(*it->second);
|
|
|
|
return shared_from(mod);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
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
|
|
|
static const load_mode::type flags
|
|
|
|
{
|
|
|
|
load_mode::rtld_local |
|
|
|
|
load_mode::rtld_now
|
|
|
|
};
|
|
|
|
|
2017-03-21 03:26:23 +01:00
|
|
|
log.debug("Attempting to load '%s' @ `%s'", filename, path.string());
|
2016-11-16 03:41:12 +01:00
|
|
|
return std::make_shared<mod>(path, flags);
|
|
|
|
}()}
|
|
|
|
{
|
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
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
2017-03-21 03:26:23 +01:00
|
|
|
log.error("Failed to load '%s': %s", name, e.what());
|
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
|
|
|
throw;
|
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
ircd::mods::module::~module()
|
|
|
|
noexcept
|
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
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
std::string
|
2016-11-29 16:23:38 +01:00
|
|
|
ircd::mods::module::path()
|
2016-11-16 03:41:12 +01:00
|
|
|
const
|
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
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
if(unlikely(!*this))
|
|
|
|
return std::string{};
|
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
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
auto &mod(**this);
|
2016-11-29 16:23:38 +01:00
|
|
|
return mod.location();
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
std::string
|
2016-11-29 16:23:38 +01:00
|
|
|
ircd::mods::module::name()
|
2016-11-16 03:41:12 +01:00
|
|
|
const
|
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
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
if(unlikely(!*this))
|
|
|
|
return std::string{};
|
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
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
auto &mod(**this);
|
2016-11-29 16:23:38 +01:00
|
|
|
return mod.name();
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
template<> uint8_t *
|
|
|
|
ircd::mods::module::ptr<uint8_t>(const std::string &name)
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2017-03-21 04:38:34 +01:00
|
|
|
auto &mod(**this);
|
|
|
|
return mod.ptr<uint8_t>(name);
|
2016-11-29 16:23:38 +01:00
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
template<>
|
|
|
|
const uint8_t *
|
|
|
|
ircd::mods::module::ptr<const uint8_t>(const std::string &name)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
const auto &mod(**this);
|
2017-03-21 04:38:34 +01:00
|
|
|
return mod.ptr<const uint8_t>(name);
|
2016-11-29 16:23:38 +01:00
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
bool
|
|
|
|
ircd::mods::module::has(const std::string &name)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
if(unlikely(!*this))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
const auto &mod(**this);
|
2017-03-21 04:38:34 +01:00
|
|
|
return mod.has(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
// sym_ptr
|
|
|
|
//
|
|
|
|
|
|
|
|
ircd::mods::sym_ptr::sym_ptr(const std::string &modname,
|
|
|
|
const std::string &symname)
|
|
|
|
:std::weak_ptr<mod>
|
|
|
|
{
|
|
|
|
module(modname)
|
|
|
|
}
|
|
|
|
,ptr{[this, &modname, &symname]
|
|
|
|
{
|
|
|
|
const life_guard<mods::mod> mod(*this);
|
|
|
|
|
|
|
|
if(unlikely(!mod->has(symname)))
|
|
|
|
throw undefined_symbol("Could not find symbol '%s' in module '%s'", symname, mod->name());
|
|
|
|
|
|
|
|
return mod->ptr(symname);
|
|
|
|
}()}
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
ircd::mods::sym_ptr::~sym_ptr()
|
|
|
|
noexcept
|
|
|
|
{
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2016-11-29 16:23:38 +01:00
|
|
|
// misc
|
2016-11-16 03:41:12 +01:00
|
|
|
//
|
|
|
|
|
|
|
|
namespace ircd {
|
|
|
|
namespace mods {
|
|
|
|
|
|
|
|
} // namespace mods
|
|
|
|
} // namespace ircd
|
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
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::loaded(const std::string &name)
|
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
return mod::loaded.count(postfixed(name));
|
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
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::available(const std::string &name)
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
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
|
|
|
using filesystem::path;
|
|
|
|
|
|
|
|
std::vector<std::string> why;
|
|
|
|
return !search(name, why).empty();
|
|
|
|
}
|
2016-03-20 12:00:20 +01:00
|
|
|
|
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
|
|
|
std::string
|
|
|
|
ircd::mods::search(const std::string &name)
|
|
|
|
{
|
|
|
|
std::vector<std::string> why;
|
|
|
|
return search(name, why);
|
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
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
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::find_symbol(const std::string &symbol)
|
|
|
|
{
|
|
|
|
std::vector<std::string> ret;
|
|
|
|
const auto av(available());
|
|
|
|
std::copy_if(begin(av), end(av), std::back_inserter(ret), [&symbol]
|
|
|
|
(const auto &name)
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
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
|
|
|
return has_symbol(name, symbol);
|
|
|
|
});
|
2016-06-18 07:52:16 +02:00
|
|
|
|
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
|
|
|
return ret;
|
|
|
|
}
|
2016-03-20 12:00:20 +01:00
|
|
|
|
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
|
|
|
bool
|
|
|
|
ircd::mods::has_symbol(const std::string &name,
|
|
|
|
const std::string &symbol)
|
|
|
|
{
|
|
|
|
const auto fullpath(search(name));
|
|
|
|
if(fullpath.empty())
|
|
|
|
return false;
|
2016-03-20 12:00:20 +01:00
|
|
|
|
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
|
|
|
const auto syms(symbols(fullpath));
|
|
|
|
return std::find(begin(syms), end(syms), symbol) != end(syms);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
filesystem::path
|
|
|
|
ircd::mods::fullpath(const std::string &name)
|
|
|
|
{
|
|
|
|
std::vector<std::string> why;
|
|
|
|
const filesystem::path path(search(name, why));
|
|
|
|
if(path.empty())
|
|
|
|
{
|
|
|
|
for(const auto &str : why)
|
2017-03-21 03:26:23 +01:00
|
|
|
log.error("candidate for module '%s' failed: %s", name, str);
|
2016-11-29 16:23:38 +01:00
|
|
|
|
2017-03-21 03:26:23 +01:00
|
|
|
throw error("No valid module by name `%s'", name);
|
2016-11-29 16:23:38 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return path;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
std::string
|
|
|
|
ircd::mods::search(const std::string &name,
|
|
|
|
std::vector<std::string> &why)
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
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
|
|
|
using filesystem::path;
|
2016-03-18 21:32:33 +01:00
|
|
|
|
2016-09-05 23:27:35 +02:00
|
|
|
const path path(postfixed(name));
|
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
|
|
|
if(!path.is_relative())
|
|
|
|
{
|
|
|
|
why.resize(why.size() + 1);
|
|
|
|
return is_module(path, why.back())? name : std::string{};
|
|
|
|
}
|
2016-11-16 03:41:12 +01:00
|
|
|
else for(const auto &dir : paths)
|
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
|
|
|
{
|
|
|
|
why.resize(why.size() + 1);
|
|
|
|
if(is_module(dir/path, why.back()))
|
|
|
|
return (dir/path).string();
|
|
|
|
}
|
|
|
|
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
|
|
|
std::forward_list<std::string>
|
|
|
|
ircd::mods::available()
|
|
|
|
{
|
|
|
|
using filesystem::path;
|
|
|
|
using filesystem::directory_iterator;
|
2007-01-25 07:40:21 +01:00
|
|
|
|
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
|
|
|
std::forward_list<std::string> ret;
|
2016-11-16 03:41:12 +01:00
|
|
|
for(const auto &dir : paths) try
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
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
|
|
|
for(directory_iterator it(dir); it != directory_iterator(); ++it)
|
|
|
|
if(is_module(it->path(), std::nothrow))
|
|
|
|
ret.emplace_front(relative(it->path(), dir).string());
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
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
|
|
|
catch(const filesystem::filesystem_error &e)
|
|
|
|
{
|
2017-03-21 03:26:23 +01:00
|
|
|
log.warning("Module path [%s]: %s", dir, e.what());
|
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
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
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
|
|
|
bool
|
|
|
|
ircd::mods::is_module(const std::string &fullpath)
|
|
|
|
{
|
|
|
|
return is_module(filesystem::path(fullpath));
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::is_module(const std::string &fullpath,
|
|
|
|
std::nothrow_t)
|
|
|
|
{
|
|
|
|
return is_module(filesystem::path(fullpath), std::nothrow);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::is_module(const std::string &fullpath,
|
|
|
|
std::string &why)
|
|
|
|
{
|
|
|
|
return is_module(filesystem::path(fullpath), why);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::is_module(const filesystem::path &path,
|
|
|
|
std::nothrow_t)
|
|
|
|
try
|
|
|
|
{
|
|
|
|
return is_module(path);
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::is_module(const filesystem::path &path,
|
|
|
|
std::string &why)
|
|
|
|
try
|
|
|
|
{
|
|
|
|
return is_module(path);
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
why = e.what();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::is_module(const filesystem::path &path)
|
|
|
|
{
|
|
|
|
if(!exists(path))
|
2017-03-21 03:26:23 +01:00
|
|
|
throw filesystem_error("`%s' does not exist", path.string());
|
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
|
|
|
|
|
|
|
if(!is_regular_file(path))
|
2017-03-21 03:26:23 +01:00
|
|
|
throw filesystem_error("`%s' is not a file", path.string());
|
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
|
|
|
|
|
|
|
const auto syms(symbols(path));
|
2016-11-02 23:12:56 +01:00
|
|
|
const auto &header_name(mapi::header_symbol_name);
|
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
|
|
|
const auto it(std::find(begin(syms), end(syms), header_name));
|
|
|
|
if(it == end(syms))
|
2017-03-21 03:26:23 +01:00
|
|
|
throw error("`%s': has no MAPI header (%s)", path.string(), header_name);
|
|
|
|
|
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
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::sections(const std::string &fullpath)
|
|
|
|
{
|
|
|
|
return sections(filesystem::path(fullpath));
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::symbols(const std::string &fullpath)
|
|
|
|
{
|
|
|
|
return symbols(filesystem::path(fullpath));
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::symbols(const std::string &fullpath,
|
|
|
|
const std::string §ion)
|
|
|
|
{
|
|
|
|
return symbols(filesystem::path(fullpath), section);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::sections(const filesystem::path &path)
|
|
|
|
{
|
2016-10-26 08:16:33 +02:00
|
|
|
return info<std::vector<std::string>>(path, []
|
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
|
|
|
return info.sections();
|
|
|
|
});
|
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
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::symbols(const filesystem::path &path)
|
|
|
|
{
|
2016-10-26 08:16:33 +02:00
|
|
|
return info<std::vector<std::string>>(path, []
|
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
|
|
|
return info.symbols();
|
|
|
|
});
|
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
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::symbols(const filesystem::path &path,
|
|
|
|
const std::string §ion)
|
|
|
|
{
|
2016-10-26 08:16:33 +02:00
|
|
|
return info<std::vector<std::string>>(path, [§ion]
|
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
|
|
|
return info.symbols(section);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class R,
|
|
|
|
class F>
|
|
|
|
R
|
|
|
|
ircd::mods::info(const filesystem::path &path,
|
|
|
|
F&& closure)
|
|
|
|
{
|
|
|
|
if(!exists(path))
|
2017-03-21 03:26:23 +01:00
|
|
|
throw filesystem_error("`%s' does not exist", path.string());
|
2016-10-26 08:16:33 +02:00
|
|
|
|
|
|
|
if(!is_regular_file(path))
|
2017-03-21 03:26:23 +01:00
|
|
|
throw filesystem_error("`%s' is not a file", path.string());
|
2016-10-26 08:16:33 +02:00
|
|
|
|
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
|
|
|
boost::dll::library_info info(path);
|
2016-10-26 08:16:33 +02:00
|
|
|
return closure(info);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2016-11-29 16:23:38 +01:00
|
|
|
// paths
|
2016-11-16 03:41:12 +01:00
|
|
|
//
|
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
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
namespace ircd {
|
|
|
|
namespace mods {
|
|
|
|
|
|
|
|
const filesystem::path modroot
|
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
|
|
|
{
|
2017-03-31 00:46:40 +02:00
|
|
|
ircd::fs::get(ircd::fs::MODULES)
|
2016-11-16 03:41:12 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
struct paths paths;
|
|
|
|
|
|
|
|
} // namespace mods
|
|
|
|
} // namespace ircd
|
|
|
|
|
|
|
|
ircd::mods::paths::paths()
|
|
|
|
:std::vector<std::string>
|
|
|
|
{{
|
|
|
|
modroot.string()
|
|
|
|
}}
|
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
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2016-11-16 03:41:12 +01:00
|
|
|
ircd::mods::paths::add(const std::string &dir)
|
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
|
|
|
{
|
|
|
|
using filesystem::path;
|
|
|
|
|
|
|
|
const path path(prefix_if_relative(dir));
|
|
|
|
|
|
|
|
if(!exists(path))
|
2017-03-21 03:26:23 +01:00
|
|
|
throw filesystem_error("path `%s' (%s) does not exist", dir, path.string());
|
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
|
|
|
|
|
|
|
if(!is_directory(path))
|
2017-03-21 03:26:23 +01:00
|
|
|
throw filesystem_error("path `%s' (%s) is not a directory", dir, path.string());
|
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
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
if(added(dir))
|
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
|
|
|
return false;
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
emplace(begin(), dir);
|
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
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
bool
|
|
|
|
ircd::mods::paths::add(const std::string &dir,
|
|
|
|
std::nothrow_t)
|
|
|
|
try
|
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
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
return add(dir);
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
log.error("Failed to add path: %s", e.what());
|
|
|
|
return false;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2016-11-16 03:41:12 +01:00
|
|
|
ircd::mods::paths::del(const std::string &dir)
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
std::remove(begin(), end(), prefix_if_relative(dir).string());
|
|
|
|
return true;
|
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
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
bool
|
|
|
|
ircd::mods::paths::added(const std::string &dir)
|
|
|
|
const
|
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
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
return std::find(begin(), end(), dir) != end();
|
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
|
|
|
}
|
2016-07-13 07:17:21 +02:00
|
|
|
|
2017-08-16 22:15:14 +02:00
|
|
|
std::string
|
|
|
|
ircd::mods::unpostfixed(const std::string &name)
|
|
|
|
{
|
|
|
|
return unpostfixed(filesystem::path(name)).string();
|
|
|
|
}
|
|
|
|
|
2016-09-05 23:27:35 +02:00
|
|
|
std::string
|
|
|
|
ircd::mods::postfixed(const std::string &name)
|
|
|
|
{
|
|
|
|
return postfixed(filesystem::path(name)).string();
|
|
|
|
}
|
|
|
|
|
|
|
|
filesystem::path
|
2017-08-16 22:15:14 +02:00
|
|
|
ircd::mods::unpostfixed(const filesystem::path &path)
|
2016-09-05 23:27:35 +02:00
|
|
|
{
|
2017-08-16 22:15:14 +02:00
|
|
|
if(extension(path) != suffix)
|
|
|
|
return path;
|
|
|
|
|
|
|
|
return filesystem::path(path).replace_extension();
|
|
|
|
}
|
2016-09-05 23:27:35 +02:00
|
|
|
|
2017-08-16 22:15:14 +02:00
|
|
|
filesystem::path
|
|
|
|
ircd::mods::postfixed(const filesystem::path &path)
|
|
|
|
{
|
2016-09-05 23:27:35 +02:00
|
|
|
if(extension(path) == suffix)
|
|
|
|
return path;
|
|
|
|
|
|
|
|
filesystem::path ret(path);
|
|
|
|
return ret += suffix;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
filesystem::path
|
|
|
|
ircd::mods::prefix_if_relative(const filesystem::path &path)
|
|
|
|
{
|
|
|
|
return path.is_relative()? (modroot / path) : path;
|
|
|
|
}
|
2016-07-13 07:17:21 +02:00
|
|
|
|
2017-08-29 02:05:05 +02:00
|
|
|
std::string
|
|
|
|
ircd::mods::demangle(const std::string &symbol)
|
|
|
|
{
|
|
|
|
size_t len;
|
|
|
|
int status;
|
|
|
|
const custom_ptr<char> buf
|
|
|
|
{
|
|
|
|
abi::__cxa_demangle(symbol.c_str(), nullptr, &len, &status),
|
|
|
|
std::free
|
|
|
|
};
|
|
|
|
|
|
|
|
switch(status)
|
|
|
|
{
|
|
|
|
case 0: break;
|
|
|
|
case -1: throw error("Demangle failed -1: memory allocation failure");
|
|
|
|
case -2: throw error("Demangle failed -2: mangled name is not valid");
|
|
|
|
case -3: throw error("Demangle failed -3: invalid argument");
|
|
|
|
default: throw error("Demangle failed %d: unknown error", status);
|
|
|
|
}
|
|
|
|
|
|
|
|
return { buf.get(), len };
|
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
2016-11-29 16:23:38 +01:00
|
|
|
// mod (internal)
|
2016-11-16 03:41:12 +01:00
|
|
|
//
|
|
|
|
|
|
|
|
namespace ircd {
|
|
|
|
namespace mods {
|
|
|
|
|
2017-03-31 00:54:17 +02:00
|
|
|
std::stack<mod *> mod::loading;
|
2016-11-16 03:41:12 +01:00
|
|
|
std::map<std::string, mod *> mod::loaded;
|
|
|
|
|
|
|
|
} // namespace mods
|
|
|
|
} // namespace ircd
|
|
|
|
|
|
|
|
ircd::mods::mod::mod(const filesystem::path &path,
|
2017-03-31 00:54:17 +02:00
|
|
|
const load_mode::type &mode)
|
2016-11-16 03:41:12 +01:00
|
|
|
try
|
2017-03-31 00:54:17 +02:00
|
|
|
:path{path}
|
|
|
|
,mode{mode}
|
|
|
|
,handle{[this, &path, &mode]
|
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
|
|
|
{
|
2017-03-31 00:54:17 +02:00
|
|
|
const auto theirs
|
|
|
|
{
|
|
|
|
std::get_terminate()
|
|
|
|
};
|
|
|
|
|
2017-03-21 05:25:07 +01:00
|
|
|
const auto ours([]
|
|
|
|
{
|
|
|
|
log.critical("std::terminate() called during the static construction of a module.");
|
|
|
|
|
|
|
|
if(std::current_exception()) try
|
|
|
|
{
|
|
|
|
std::rethrow_exception(std::current_exception());
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
log.error("%s", e.what());
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2017-03-31 00:54:17 +02:00
|
|
|
const scope reset{[this, &theirs]
|
2017-03-21 05:25:07 +01:00
|
|
|
{
|
2017-03-31 00:54:17 +02:00
|
|
|
assert(loading.top() == this);
|
|
|
|
loading.pop();
|
2017-03-21 05:25:07 +01:00
|
|
|
|
|
|
|
std::set_terminate(theirs);
|
|
|
|
}};
|
|
|
|
|
2017-03-31 00:54:17 +02:00
|
|
|
loading.push(this);
|
2017-03-21 05:25:07 +01:00
|
|
|
std::set_terminate(ours);
|
2017-03-31 00:54:17 +02:00
|
|
|
return boost::dll::shared_library{path, mode};
|
2017-03-21 05:25:07 +01:00
|
|
|
}()}
|
2016-11-16 03:41:12 +01:00
|
|
|
,header
|
2007-01-25 07:40:21 +01:00
|
|
|
{
|
2016-11-16 03:41:12 +01:00
|
|
|
&handle.get<mapi::header>(mapi::header_symbol_name)
|
|
|
|
}
|
|
|
|
{
|
2017-03-21 03:26:23 +01:00
|
|
|
log.debug("Loaded static segment of '%s' @ `%s'", name(), path.string());
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
if(unlikely(!header))
|
|
|
|
throw error("Unexpected null header");
|
|
|
|
|
2017-03-18 01:45:43 +01:00
|
|
|
if(header->magic != mapi::MAGIC)
|
2017-03-21 03:26:23 +01:00
|
|
|
throw error("Bad magic [%04x] need: [%04x]", header->magic, mapi::MAGIC);
|
2016-11-16 03:41:12 +01:00
|
|
|
|
|
|
|
// Set some basic metadata
|
|
|
|
auto &meta(header->meta);
|
|
|
|
meta["name"] = name();
|
|
|
|
meta["location"] = location();
|
|
|
|
|
2017-03-31 00:54:17 +02:00
|
|
|
if(!loading.empty())
|
|
|
|
{
|
|
|
|
const auto &m(mod::loading.top());
|
2017-04-03 07:59:30 +02:00
|
|
|
m->children.emplace_back(this);
|
2017-03-31 00:54:17 +02:00
|
|
|
log.debug("Module '%s' recursively loaded by '%s'",
|
|
|
|
name(),
|
|
|
|
m->path.filename().string());
|
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
// If init throws an exception from here the loading process will back out.
|
|
|
|
if(header->init)
|
|
|
|
header->init();
|
|
|
|
|
2017-03-31 00:54:17 +02:00
|
|
|
log.info("Loaded module %s v%u \"%s\" (depth: %zu)",
|
2017-03-21 03:26:23 +01:00
|
|
|
name(),
|
2016-11-16 03:41:12 +01:00
|
|
|
header->version,
|
2017-03-31 00:54:17 +02:00
|
|
|
description().size()? description() : "<no description>"s,
|
|
|
|
loading.size());
|
|
|
|
|
|
|
|
// Without init exception, the module is now considered loaded.
|
|
|
|
loaded.emplace(name(), this);
|
2016-11-16 03:41:12 +01:00
|
|
|
}
|
|
|
|
catch(const boost::system::system_error &e)
|
|
|
|
{
|
2017-08-29 02:05:31 +02:00
|
|
|
switch(e.code().value())
|
|
|
|
{
|
|
|
|
case boost::system::errc::bad_file_descriptor:
|
|
|
|
{
|
|
|
|
const string_view what(e.what());
|
|
|
|
const auto pos(what.find("undefined symbol: "));
|
|
|
|
if(pos == std::string_view::npos)
|
|
|
|
break;
|
|
|
|
|
|
|
|
const string_view msg(what.substr(pos));
|
|
|
|
const std::string mangled(between(msg, ": ", ")"));
|
|
|
|
const std::string demangled(demangle(mangled));
|
|
|
|
throw error("undefined symbol: '%s' (%s)",
|
|
|
|
demangled,
|
|
|
|
mangled);
|
|
|
|
}
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
throw error("%s", e.what());
|
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
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
// Allows module to communicate static destruction is taking place when mapi::header
|
|
|
|
// destructs. If dlclose() returns without this being set, dlclose() lied about really
|
|
|
|
// unloading the module. That is considered a "stuck" module.
|
|
|
|
bool ircd::mapi::static_destruction;
|
|
|
|
|
|
|
|
ircd::mods::mod::~mod()
|
|
|
|
noexcept try
|
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
|
|
|
{
|
2017-04-03 07:59:30 +02:00
|
|
|
unload();
|
|
|
|
}
|
|
|
|
catch(const std::exception &e)
|
|
|
|
{
|
|
|
|
log::critical("Module @%p unload: %s", (const void *)this, e.what());
|
|
|
|
|
|
|
|
if(!ircd::debugmode)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::mod::unload()
|
|
|
|
{
|
|
|
|
if(!handle.is_loaded())
|
|
|
|
return false;
|
|
|
|
|
2016-11-16 03:41:12 +01:00
|
|
|
const auto name(this->name());
|
2017-03-21 03:26:23 +01:00
|
|
|
log.debug("Attempting unload module '%s' @ `%s'", name, location());
|
2016-11-16 03:41:12 +01:00
|
|
|
const size_t erased(loaded.erase(name));
|
|
|
|
assert(erased == 1);
|
|
|
|
|
|
|
|
if(header->fini)
|
|
|
|
header->fini();
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2017-04-03 07:59:30 +02:00
|
|
|
// Save the children! dlclose() does not like to be called recursively during static
|
|
|
|
// destruction of a module. The mod ctor recorded all of the modules loaded while this
|
|
|
|
// module was loading so we can reverse the record and unload them here.
|
|
|
|
// Note: If the user loaded more modules from inside their module they will have to dtor them
|
|
|
|
// before 'static destruction' does. They can also do that by adding them to this vector.
|
|
|
|
std::for_each(rbegin(this->children), rend(this->children), []
|
|
|
|
(mod *const &ptr)
|
|
|
|
{
|
|
|
|
if(shared_from(*ptr).use_count() <= 2)
|
|
|
|
ptr->unload();
|
|
|
|
});
|
|
|
|
|
2017-03-21 03:26:23 +01:00
|
|
|
log.debug("Attempting static unload for '%s' @ `%s'", name, location());
|
2016-11-16 03:41:12 +01:00
|
|
|
mapi::static_destruction = false;
|
|
|
|
handle.unload();
|
|
|
|
assert(!handle.is_loaded());
|
|
|
|
if(!mapi::static_destruction)
|
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
|
|
|
{
|
2017-03-21 03:26:23 +01:00
|
|
|
log.error("Module \"%s\" is stuck and failing to unload.", name);
|
|
|
|
log.warning("Module \"%s\" may result in undefined behavior if not fixed.", name);
|
2016-11-16 03:41:12 +01:00
|
|
|
} else {
|
2017-03-21 03:26:23 +01:00
|
|
|
log.info("Unloaded '%s'", name);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2017-04-03 07:59:30 +02:00
|
|
|
return true;
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
template<class T>
|
|
|
|
T *
|
|
|
|
ircd::mods::mod::ptr(const std::string &name)
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
{
|
2016-11-29 16:23:38 +01:00
|
|
|
return &handle.get<T>(name);
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
}
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
template<class T>
|
|
|
|
const T *
|
|
|
|
ircd::mods::mod::ptr(const std::string &name)
|
|
|
|
const
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
{
|
2016-11-29 16:23:38 +01:00
|
|
|
return &handle.get<T>(name);
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
}
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
template<class T>
|
|
|
|
T &
|
|
|
|
ircd::mods::mod::get(const std::string &name)
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
{
|
2016-11-29 16:23:38 +01:00
|
|
|
handle.get<T>(name);
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
}
|
|
|
|
|
2016-11-29 16:23:38 +01:00
|
|
|
template<class T>
|
|
|
|
const T &
|
|
|
|
ircd::mods::mod::get(const std::string &name)
|
|
|
|
const
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
{
|
2016-11-29 16:23:38 +01:00
|
|
|
handle.get<T>(name);
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2016-11-29 16:23:38 +01:00
|
|
|
ircd::mods::mod::has(const std::string &name)
|
|
|
|
const
|
MAPI Version 3
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.
2016-06-23 03:30:05 +02:00
|
|
|
{
|
2016-11-29 16:23:38 +01:00
|
|
|
return handle.has(name);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|