Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Allowing Plugin Interdependency and Improving Plugin Management
dmoore:
--- Quote from: oBFusCATed on November 10, 2013, 09:28:18 pm ---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?
--- End quote ---
Some, C::B still has to read all of the manifests, but no DLLs for disabled plugins get loaded. I will do some timings when I have time.
dmoore:
--- Quote from: oBFusCATed on November 10, 2013, 09:26:52 pm ---
--- 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.
--- End quote ---
That's obviously a choice you can make per plugin. But what are you proposing as the alternative? The way wxSmith does it? i.e. A separate lib for common stuff that all plugins import. That sucks for deployment because what I found was that the common lib needs to be in the same place as libcodeblocks (the way we do it on windows) or in one of the system lib paths (unix). So much for manage plugins -> install new...
--- Quote ---
--- 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.
--- End quote ---
Sure, my intention was only to figure out what's possible now NOT how it should work. I don't think it would be terribly complicated expose the relevant parts of the compiler plugin to another plugin.
--- Quote ---I'm not sure also that it is a good idea to allow plugins to depend on other plugins
--- End quote ---
Not what you said in the other thread... ???
--- Quote ---and I think if something should be accessed by more plugins it is better to provide a SDK API for it.
--- End quote ---
If you mean adding to the C::B SDK, that just bloats C::B unnecessarily e.g Most of the devs couldn't give a shit about python support, but there are a bunch of common things in my python plugins (e.g. XMLRPC stuff) that I would like all of my plugins to be able to use. No reason to have this in the C::B SDK, but I would still like some method of deploying this shared library using our existing plugin management mechanisms
Another example is Tools+. Initially I had the part that provides that notebook tabs built as a separate library so that more than one plugin could define windows that would be displayed there (e.g. output from shell commands, a python interpreter). There is no reason this necessarily needs to be part of the SDK if it isn't being used.
Curious to hear what others think. I won't spend any more time on this if enough of you think this is a dead end.
oBFusCATed:
--- Quote from: dmoore on November 10, 2013, 11:55:11 pm ---Not what you said in the other thread... ???
--- End quote ---
I'm not sure what are you referring here. I've just said that if we need to have one plugin depend on another, then doing this as part of the plugin manager is the right way to do it.
--- Quote from: dmoore on November 10, 2013, 11:55:11 pm ---... but I would still like some method of deploying this shared library using our existing plugin management mechanisms
--- End quote ---
One way is using static libraries. With -fvisibility=hidden plus some other useful options the linker is able to remove the unused code.
Another option is using -rpath, but I'm not sure if it is available on windows or osx.
--- Quote from: dmoore on November 10, 2013, 11:55:11 pm ---Another example is Tools+.
--- End quote ---
I've always felt that the tools+ should have been written over the original code and thus the old code removed. And this is the reason I'm not using the Tools+.
C::B has one very serious problem - it has tons of features that look like each other: tools/tools+, build-in search/threadsearch/incremental search.
We should try to do a better job in this regard - copy the good parts from all implementation and remove the bad once or at least extracting built-in tools and built-in search in plugins.
--- Quote from: dmoore on November 10, 2013, 11:55:11 pm ---Curious to hear what others think. I won't spend any more time on this if enough of you think this is a dead end.
--- End quote ---
As I've said in the other topic: if you need this feature go on and implement it. Handling dependencies automatically is the only proper way to do this if you need it. Playing with the weights and so on is just a hack.
beqroson:
--- Quote from: dmoore on November 10, 2013, 11:55:11 pm ---Curious to hear what others think. I won't spend any more time on this if enough of you think this is a dead end.
--- End quote ---
I dont know much about the inner workings of Codeblocks. But it sounds useful to me. If one plugin does a few things on disc for example, like scanning a lot of header files. Instead of another plugin doing the same thing, it could get the result from the first plugin. If two plugins need the same mechanism that would not use amounts of resources, however, it would be better if each plugin manages on its own. Also, it would be necessary to select such behavior that does not really change over longer periods of time. If the interface of the plugin would change or the format of the data, then the interdependency could break too often for it to be usable. The best thing would be that the interdependency actually never breaks, which would demand that the plugin kept backwards compatible of its inner workings. Compare with DLL-hell.
dmoore:
--- Quote from: dmoore on November 10, 2013, 09:52:32 pm ---
--- Quote from: oBFusCATed on November 10, 2013, 09:28:18 pm ---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?
--- End quote ---
Some, C::B still has to read all of the manifests, but no DLLs for disabled plugins get loaded. I will do some timings when I have time.
--- End quote ---
Some timings on an i386 laptop
Results for safemode
--- Code: ---time codeblocks --safe-mode -ns -ni --multiple-instance (quitting immediately after)
before: ~10.0s first time*, ~5.8s subsequently
after: ~2.8s first time*, ~2.6s subsequently
--- End code ---
* NOT from cold start (so don't trust these numbers)
Results with only core plugins enabled
--- Code: ---time codeblocks -ns -ni --multiple-instance (quitting immediately after)
before: ~8.1s**
after: ~5.3s**
--- End code ---
** based on second and subsequent runs
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version