Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Compile on demand plugin

<< < (5/6) > >>

frithjofh:
hi everybody,

how about creating a hierarchy of plugins. one base class. one derived "independent" plugin, one derived "dependent" plugin. "dependent" plugins are all those that rely on another plugin to be loaded. they only get loaded by the manager once all "independent" plugins are on line.

regards

oBFusCATed:
Patches welcome...

frithjofh:
very kind...

I would very much like to know what you think of it too...

what I thought:

-changes to existing plugins are small because they already depend on a base class. this would be the one that is altered, but opaque to the derived plugin. change would be foremost inside the manager

-the interdependency of plugins is really not very deep, so maybe with just two levels/types it would be enough. some numbering/weighing would be overkill

-first class "independent" plugins would be limited to a small set of core plugins. almost the same group as now already included in source as top level plugins

oBFusCATed:

--- Quote from: frithjofh on November 08, 2013, 08:10:49 pm ---I would very much like to know what you think of it too...

--- End quote ---
This is the proper way to do a plugin's api, but unfortunately no one has the time to do it or enough personal need for it.

dmoore:

--- Quote from: oBFusCATed on November 08, 2013, 09:24:52 pm ---This is the proper way to do a plugin's api, but unfortunately no one has the time to do it or enough personal need for it.

--- End quote ---

A vote for personal need... In the attached patch, I've started playing with deferring the loading of plugins until they are actually needed. The patch has some issues with installing new plugins and makes the already weak encapsulation of pluginmanager stuff worse, but it MOSTLY works.

I am now thinking about how to address the dependencies between plugins. Instead of dependent and independent, I think it makes more sense for each plugin to state their dependencies in the manifest. So if plugin A depends on the compiler plugin, then when the user disables the compiler plugin, the framework will know to disable plugin A first. Thoughts?

Btw, does anyone know how to update the shared library search directories from within C::B at runtime? By default, the plugin dirs are not in the library search path but they need to be put there once C::B starts up in order to handle dependencies.

Navigation

[0] Message Index

[#] Next page

[*] Previous page