2018-02-04 03:22:01 +01:00
|
|
|
// Matrix Construct
|
|
|
|
//
|
|
|
|
// Copyright (C) Matrix Construct Developers, Authors & Contributors
|
|
|
|
// Copyright (C) 2016-2018 Jason Volk <jason@zemos.net>
|
|
|
|
//
|
|
|
|
// Permission to use, copy, modify, and/or distribute this software for any
|
|
|
|
// purpose with or without fee is hereby granted, provided that the above
|
|
|
|
// copyright notice and this permission notice is present in all copies. The
|
|
|
|
// full license for this software is available in the LICENSE file.
|
2007-01-25 07:40:21 +01:00
|
|
|
|
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;
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
#include <ircd/asio.h>
|
2016-11-29 16:23:38 +01:00
|
|
|
#include <ircd/mapi.h> // Module's internal API
|
2018-02-09 08:35:42 +01:00
|
|
|
#include "mods.h"
|
2017-12-02 22:07:55 +01:00
|
|
|
|
|
|
|
ircd::log::log
|
|
|
|
ircd::mods::log
|
|
|
|
{
|
|
|
|
"modules", 'M'
|
|
|
|
};
|
|
|
|
|
|
|
|
const filesystem::path
|
|
|
|
ircd::mods::suffix
|
|
|
|
{
|
|
|
|
boost::dll::shared_library::suffix()
|
|
|
|
};
|
|
|
|
|
|
|
|
std::stack<ircd::mods::mod *>
|
|
|
|
ircd::mods::mod::loading
|
|
|
|
{};
|
|
|
|
|
|
|
|
std::map<std::string, ircd::mods::mod *>
|
|
|
|
ircd::mods::mod::loaded
|
|
|
|
{};
|
|
|
|
|
2018-02-09 08:35:42 +01:00
|
|
|
//
|
|
|
|
// mod (internal)
|
|
|
|
//
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
ircd::mods::mod::mod(const filesystem::path &path,
|
|
|
|
const load_mode::type &mode)
|
|
|
|
try
|
|
|
|
:path{path}
|
|
|
|
,mode{mode}
|
|
|
|
,mangles{mods::mangles(path)}
|
|
|
|
,handle{[this, &path, &mode]
|
2017-08-16 22:15:14 +02:00
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
const auto theirs
|
|
|
|
{
|
|
|
|
std::get_terminate()
|
|
|
|
};
|
|
|
|
|
|
|
|
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());
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
const unwind reset{[this, &theirs]
|
|
|
|
{
|
|
|
|
assert(loading.top() == this);
|
|
|
|
loading.pop();
|
|
|
|
std::set_terminate(theirs);
|
|
|
|
}};
|
|
|
|
|
|
|
|
loading.push(this);
|
|
|
|
std::set_terminate(ours);
|
|
|
|
return boost::dll::shared_library{path, mode};
|
|
|
|
}()}
|
|
|
|
,_name
|
|
|
|
{
|
|
|
|
handle.location().filename().string()
|
|
|
|
}
|
|
|
|
,_location
|
|
|
|
{
|
|
|
|
handle.location().string()
|
|
|
|
}
|
|
|
|
,header
|
|
|
|
{
|
|
|
|
&handle.get<mapi::header>(mapi::header_symbol_name)
|
|
|
|
}
|
|
|
|
{
|
|
|
|
log.debug("Loaded static segment of '%s' @ `%s' with %zu symbols",
|
|
|
|
name(),
|
|
|
|
location(),
|
|
|
|
mangles.size());
|
2017-08-16 22:15:14 +02:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
if(unlikely(!header))
|
|
|
|
throw error("Unexpected null header");
|
|
|
|
|
|
|
|
if(header->magic != mapi::MAGIC)
|
|
|
|
throw error("Bad magic [%04x] need: [%04x]",
|
|
|
|
header->magic,
|
|
|
|
mapi::MAGIC);
|
|
|
|
|
|
|
|
// Set some basic metadata
|
|
|
|
auto &meta(header->meta);
|
|
|
|
meta["name"] = name();
|
|
|
|
meta["location"] = location();
|
2016-09-05 23:27:35 +02:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
if(!loading.empty())
|
|
|
|
{
|
|
|
|
const auto &m(mod::loading.top());
|
|
|
|
m->children.emplace_back(this);
|
|
|
|
log.debug("Module '%s' recursively loaded by '%s'",
|
|
|
|
name(),
|
|
|
|
m->path.filename().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
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
// If init throws an exception from here the loading process will back out.
|
|
|
|
if(header->init)
|
|
|
|
header->init();
|
2016-11-29 16:23:38 +01:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
log.info("Loaded module %s v%u \"%s\"",
|
|
|
|
name(),
|
|
|
|
header->version,
|
|
|
|
description().size()? description() : "<no description>"s);
|
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-12-02 22:07:55 +01:00
|
|
|
// Without init exception, the module is now considered loaded.
|
|
|
|
loaded.emplace(name(), this);
|
|
|
|
}
|
|
|
|
catch(const boost::system::system_error &e)
|
2016-11-29 16:23:38 +01:00
|
|
|
{
|
2017-12-02 22:07:55 +01: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;
|
2016-11-29 16:23:38 +01:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
throw error("%s", string(e));
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
|
|
|
|
const auto name(this->name());
|
|
|
|
log.debug("Attempting unload module '%s' @ `%s'", name, location());
|
|
|
|
const size_t erased(loaded.erase(name));
|
|
|
|
assert(erased == 1);
|
|
|
|
|
|
|
|
if(header->fini)
|
|
|
|
header->fini();
|
|
|
|
|
|
|
|
// 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();
|
|
|
|
});
|
|
|
|
|
|
|
|
log.debug("Attempting static unload for '%s' @ `%s'", name, location());
|
|
|
|
mapi::static_destruction = false;
|
|
|
|
handle.unload();
|
|
|
|
assert(!handle.is_loaded());
|
|
|
|
if(!mapi::static_destruction)
|
|
|
|
{
|
|
|
|
log.error("Module \"%s\" is stuck and failing to unload.", name);
|
|
|
|
log.warning("Module \"%s\" may result in undefined behavior if not fixed.", name);
|
|
|
|
} else {
|
|
|
|
log.info("Unloaded '%s'", name);
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
const std::string &
|
|
|
|
ircd::mods::mod::mangle(const std::string &name)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
const auto it(mangles.find(name));
|
|
|
|
if(it == end(mangles))
|
|
|
|
return name;
|
|
|
|
|
|
|
|
const auto &mangled(it->second);
|
|
|
|
return mangled;
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class T>
|
|
|
|
T *
|
|
|
|
ircd::mods::mod::ptr(const std::string &name)
|
|
|
|
{
|
|
|
|
return &handle.get<T>(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class T>
|
|
|
|
const T *
|
|
|
|
ircd::mods::mod::ptr(const std::string &name)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
return &handle.get<T>(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class T>
|
|
|
|
T &
|
|
|
|
ircd::mods::mod::get(const std::string &name)
|
|
|
|
{
|
|
|
|
handle.get<T>(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
template<class T>
|
|
|
|
const T &
|
|
|
|
ircd::mods::mod::get(const std::string &name)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
handle.get<T>(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
ircd::mods::mod::has(const std::string &name)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
return handle.has(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
|
|
|
|
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
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
const 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))
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
|
|
|
static const std::string empty;
|
|
|
|
return empty;
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
const 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))
|
2017-12-02 22:07:55 +01:00
|
|
|
{
|
|
|
|
static const std::string empty;
|
|
|
|
return empty;
|
|
|
|
}
|
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);
|
2017-12-02 22:07:55 +01:00
|
|
|
return mod.ptr<uint8_t>(mangle(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-12-02 22:07:55 +01:00
|
|
|
return mod.ptr<const uint8_t>(mangle(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-12-02 22:07:55 +01:00
|
|
|
return mod.has(mangle(name));
|
|
|
|
}
|
|
|
|
|
|
|
|
const std::string &
|
|
|
|
ircd::mods::module::mangle(const std::string &name)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
if(unlikely(!*this))
|
|
|
|
{
|
|
|
|
static const std::string empty;
|
|
|
|
return empty;
|
|
|
|
}
|
|
|
|
|
|
|
|
const auto &mod(**this);
|
|
|
|
return mod.mangle(name);
|
2017-03-21 04:38:34 +01:00
|
|
|
}
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
|
2017-03-21 04:38:34 +01:00
|
|
|
///////////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
// 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]
|
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
const life_guard<mods::mod> mod{*this};
|
|
|
|
const auto &mangled(mod->mangle(symname));
|
|
|
|
if(unlikely(!mod->has(mangled)))
|
|
|
|
throw undefined_symbol
|
|
|
|
{
|
|
|
|
"Could not find symbol '%s' (%s) in module '%s'",
|
|
|
|
symname,
|
|
|
|
mangled,
|
|
|
|
mod->name()
|
|
|
|
};
|
2017-03-21 04:38:34 +01:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
return mod->ptr(mangled);
|
2017-03-21 04:38:34 +01:00
|
|
|
}()}
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
std::unordered_map<std::string, std::string>
|
|
|
|
ircd::mods::mangles(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
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
return mangles(filesystem::path(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
|
|
|
}
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
std::unordered_map<std::string, std::string>
|
|
|
|
ircd::mods::mangles(const std::string &fullpath,
|
|
|
|
const std::string §ion)
|
|
|
|
{
|
|
|
|
return mangles(filesystem::path(fullpath), section);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unordered_map<std::string, std::string>
|
|
|
|
ircd::mods::mangles(const filesystem::path &path)
|
|
|
|
{
|
|
|
|
return mangles(mods::symbols(path));
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unordered_map<std::string, std::string>
|
|
|
|
ircd::mods::mangles(const filesystem::path &path,
|
|
|
|
const std::string §ion)
|
|
|
|
{
|
|
|
|
return mangles(mods::symbols(path, section));
|
|
|
|
}
|
|
|
|
|
|
|
|
std::unordered_map<std::string, std::string>
|
|
|
|
ircd::mods::mangles(const std::vector<std::string> &symbols)
|
|
|
|
{
|
|
|
|
std::unordered_map<std::string, std::string> ret;
|
|
|
|
for(const auto &sym : symbols) try
|
|
|
|
{
|
|
|
|
ret.emplace(demangle(sym), sym);
|
|
|
|
}
|
|
|
|
catch(const not_mangled &e)
|
|
|
|
{
|
|
|
|
ret.emplace(sym, sym);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::symbols(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
|
|
|
{
|
|
|
|
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>
|
2017-12-02 22:07:55 +01:00
|
|
|
ircd::mods::symbols(const filesystem::path &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
|
|
|
{
|
2016-10-26 08:16:33 +02:00
|
|
|
return info<std::vector<std::string>>(path, []
|
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
return info.symbols();
|
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
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
2017-12-02 22:07:55 +01:00
|
|
|
ircd::mods::symbols(const filesystem::path &path,
|
|
|
|
const std::string §ion)
|
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-12-02 22:07:55 +01:00
|
|
|
return info<std::vector<std::string>>(path, [§ion]
|
2016-10-26 08:16:33 +02:00
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
return info.symbols(section);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
2017-12-02 22:07:55 +01:00
|
|
|
ircd::mods::sections(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
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
return sections(filesystem::path(fullpath));
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<std::string>
|
|
|
|
ircd::mods::sections(const filesystem::path &path)
|
|
|
|
{
|
|
|
|
return info<std::vector<std::string>>(path, []
|
2016-10-26 08:16:33 +02:00
|
|
|
(boost::dll::library_info &info)
|
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
return info.sections();
|
2016-10-26 08:16:33 +02:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
namespace ircd::mods
|
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-12-02 22:07:55 +01:00
|
|
|
const filesystem::path modroot
|
|
|
|
{
|
|
|
|
ircd::fs::get(ircd::fs::MODULES)
|
|
|
|
};
|
2016-11-16 03:41:12 +01:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
struct paths paths;
|
|
|
|
}
|
2016-11-16 03:41:12 +01:00
|
|
|
|
|
|
|
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
|
2017-09-21 04:29:36 +02:00
|
|
|
ircd::demangle(const std::string &symbol)
|
2017-08-29 02:05:05 +02:00
|
|
|
{
|
2017-09-22 07:52:16 +02:00
|
|
|
size_t len(0);
|
|
|
|
int status(0);
|
2017-08-29 02:05:05 +02:00
|
|
|
const custom_ptr<char> buf
|
|
|
|
{
|
|
|
|
abi::__cxa_demangle(symbol.c_str(), nullptr, &len, &status),
|
|
|
|
std::free
|
|
|
|
};
|
|
|
|
|
|
|
|
switch(status)
|
|
|
|
{
|
2017-12-02 22:07:55 +01:00
|
|
|
case 0:
|
2017-08-29 02:05:31 +02:00
|
|
|
break;
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
case -1:
|
|
|
|
throw mods::demangle_error("Demangle failed -1: memory allocation failure");
|
2016-11-16 03:41:12 +01:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
case -2:
|
|
|
|
throw mods::not_mangled("Demangle failed -2: mangled name '%s' is not valid", symbol);
|
2007-01-25 07:40:21 +01:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
case -3:
|
|
|
|
throw mods::demangle_error("Demangle failed -3: invalid argument");
|
2017-04-03 07:59:30 +02:00
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
default:
|
|
|
|
throw mods::demangle_error("Demangle failed %d: unknown error", status);
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
if(unlikely(!len))
|
|
|
|
return {};
|
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
|
|
|
|
2017-12-02 22:07:55 +01:00
|
|
|
return std::string { buf.get(), strnlen(buf.get(), len) };
|
2007-01-25 07:40:21 +01:00
|
|
|
}
|