Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Allowing Plugin Interdependency and Improving Plugin Management

(1/9) > >>

dmoore:
Making a new thread based on the discussion started here.

The main ideas:
1. Only load plugin shared library objects for plugins that are enabled
2. Allow plugins to interact with each other. e.g. a compiler add-on plugin might use methods provided by the compiler plugin.

Attached is a patch for #1, which is a work in progress. PluginManager does some stuff with member variables being shared across functions that make it prone to bugs when making changes and, ideally, that should be fixed as part of any overhaul.

I am working on part 2.

dmoore:
Patch updated to handle safemode

dmoore:
Some additional thoughts on plugin dependencies

At least on Linux It looks like it is possible to have a plugin compile against another plugin and use its plugin instance without too much trouble if the SOs/DLLs will be in the same place. See the attached plugin that is made to depend on the Compiler plugin (you will need to change some of the hardcoded paths in "Build Options" -> "Search Directories").

Just need to include the relevant plugin headers

--- Code: ---#include <compilergcc.h>

--- End code ---

and trivial usage:

--- Code: ---void Dep_Plugin::OnAttach()
{
    cbPlugin *plug = Manager::Get()->GetPluginManager()->FindPluginByName(_T("Compiler"));
    if (plug)
    {
        cbCompilerPlugin *cplug = dynamic_cast<cbCompilerPlugin*>(plug);
        bool attached = cplug->IsAttached();
        Manager::Get()->GetLogManager()->Log(wxString::Format(_T("Dep plugin found compiler plugin instance %i"),attached));
    }
}

--- End code ---

So I think that the only changes to the SDK that are needed:
1. make sure that our dependent plugins are loaded after the plugins they depend on
2. don't load plugins if the plugins they depend on aren't loaded
3. unload plugins if the plugins they depend on are disabled/removed


[attachment deleted by admin]

oBFusCATed:

--- Quote from: dmoore on November 10, 2013, 08:08:45 pm ---At least on Linux It looks like it is possible to have a plugin compile against another plugin and use its plugin instance....

--- End quote ---
This is because on linux we use -fvisibility=default and this will change in the future, when I have some free time to play with this.
On windows the default is -fvisibility=hidden, so this won't work anyway.


--- Quote from: dmoore on November 10, 2013, 08:08:45 pm ---Just need to include the relevant plugin headers

--- Code: ---#include <compilergcc.h>

--- End code ---

--- End quote ---
This is bloody dangerous. Nothing in this header is intended for external plugin access.
If you want to access code from other plugins, you'll have to define a clear interface which can be guaranteed to be relatively stable.

I'm not sure also that it is a good idea to allow plugins to depend on other plugins
and I think if something should be accessed by more plugins it is better to provide a SDK API for it.
This way we have a bit clearer interface. But this is just me.

oBFusCATed:
On a separate topic:
Have you measured the time needed to load C::B with and without your patch.
Currently C::B loads pretty slow if all contrib plugins are installed, but disabled.
Does you patch improve the load time?

Navigation

[0] Message Index

[#] Next page