I hope you're aware that the code below will break the moment we introduce -fvisibility-hidden to build options.
Also be aware that dynamic_cast doesn't work for dlopened shared libraries on linux (don't know if you've tried it already...).
I know that this is a bad solution and no i have not tested it on linux yet. Thank you for the hint!
How do i come from a compiler ID (or better build target) to the corresponding compiler plugin? There seems no connection between
class Compiler <-> class cbCompilerPlugin
if i look at the debugger plugin it simply uses the first compiler it can find:
// make sure the target is compiled
const std::vector<cbCompilerPlugin*> &compilers = Manager::Get()->GetPluginManager()->GetCompilerPlugins();
if (compilers.empty())
m_pCompiler = nullptr;
else
m_pCompiler = compilers.front();
if (m_pCompiler)
{
// is the compiler already running?
if (m_pCompiler->IsRunning())
{
Log(_("Compiler in use..."));
Log(_("Aborting debugging session"));
cbMessageBox(_("The compiler is currently in use. Aborting debugging session..."),
_("Compiler running"), wxICON_WARNING);
return false;
}
Log(_("Building to ensure sources are up-to-date"));
m_WaitingCompilerToFinish = true;
m_pCompiler->Build();
// now, when the build is finished, DoDebug will be launched in OnCompilerFinished()
}
Is this really the right way? Shouldn't the build process be called from a central instance, that knows the association between compiler id and compiler plugin?
I know at the moment there is only one central compiler plugin, but the API seems to suggest that there are multiple compiler plugins available, so this does not seem to be consequent...
Anyway, i will use the debugger way for now. Thank you again, you probably saved me a lot debugging work on linux.