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

Allowing Plugin Interdependency and Improving Plugin Management

<< < (3/9) > >>

dmoore:

--- Quote from: oBFusCATed on November 11, 2013, 12:15:54 am ---
--- 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.

--- End quote ---

But how do you avoid linking one plugin against some subset of another?


--- Quote ---
--- 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.

--- End quote ---

Not sure what you mean, but probably because I don't sufficiently understand shared object linking. Suppose we have plugin A, plugin B and a library C that they both depend on. If I statically link A and C, how do I make sure B can find the stuff in C?


--- Quote ---
--- 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.

--- End quote ---

Agree, it's just a bit more work to make sure Tools+ properly duplicates the old features (and clean up the UI) then remove the old stuff from C::B core. (There are historical reasons why it is the way it is, but they don't matter here.) But even if we do that, to allow other plugins to use Tools+ features means putting some of that stuff in the SDK or allowing for some way for plugins to depend on one another.


--- Quote ---
--- 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.

--- End quote ---

I wasn't proposing weights, I was proposing an explicit dependency chain be specified in the manifest (i.e. a "dependency" attribute with a comma separated list of the unique names of the plugins that it depends on). I don't think you can get by with just trying to load the lib and praying it works.

oBFusCATed:

--- Quote from: dmoore on November 11, 2013, 12:50:50 am ---Not sure what you mean, but probably because I don't sufficiently understand shared object linking. Suppose we have plugin A, plugin B and a library C that they both depend on. If I statically link A and C, how do I make sure B can find the stuff in C?

--- End quote ---
A static lib is just an archive with object files, so if you link both A and B to C (which is static lib), then both A and B will have all the code in C.
A and B will have their own copy of the code, nothing will be shared and they will have no external dependency to C. They will be self-sufficient.

In this case the data structures for A and B will be separate/duplicated in memory.

p.s. about the weights: I've mentioned it because it is another simpler approach to handle plugin deps.

dmoore:

--- Quote from: oBFusCATed on November 11, 2013, 02:40:25 am ---In this case the data structures for A and B will be separate/duplicated in memory.

--- End quote ---

That's a non-solution.


--- Quote from: oBFusCATed on November 11, 2013, 02:40:25 am ---p.s. about the weights: I've mentioned it because it is another simpler approach to handle plugin deps.

--- End quote ---

But fundamentally broken. if you disable a plugin with weight >X then you would have to unload all plugins with weight < X to be sure you haven't just crippled (and made unstable) a dependent plugin.

Your philosophical objection to linking plugins together doesn't make a lot of sense to me. It sort of sounds like you are trying to sandbox plugins, but when plugins can link against any lib in the system it isn't really much of a sandbox. And it's not like our plugins expose the user to any more risk than C::B itself -- even scripts have access to wxExecute. So what am I missing? That it's just cleaner to link against a common lib (a la wxSmith) than linking plugins together?

A real problem is the technical one i.e. the need to use -rpath (or, on windows, AddDllDirectory). The former only lets you set a link directory relative to $ORIGIN, which would make it impossible to put objects that a plugin depends on in users home.

I guess I can live with using the approach we use for wxSmith and putting all of the shared stuff in a separate lib in the same dir as libcodeblocks (or some other dir that we can -rpath to). It makes a deployment a bit more of a pain unless the core plugin is part of contrib because we don't have a mechanism for installing the shared libs from a cbplugin, which, at least on linux, requires admin rights. But maybe that's what I/we should work on?

oBFusCATed:
Hm, I think I'm being misunderstood. I don't like the idea of having plugins for plugins, I'm relatively ok with the idea of plugin communications.
So, lets stop arguing and just do it if you need it.

Have you though of putting all of your python subplugins in a single binary? I think this is possible already in C::B and probably will be easier for the user. :)

frithjofh:
maybe not plugins for plugins.

maybe some base functionality inside c::b like services. these provide interface and API. the work internally with plugins that implement and parametrize the service.

then, outside, plugins that use the services through their public interface.

that way the plugins wont be depending on each other. only outside plugins on services.

maybe some functionalities of c::b are already so general, that actually no one ever unloads the plugin representing that functionality. maybe some things have been plugins for so long that nobody questions if they really should be plugins... or at least plugins directly exposed to the user. defintely if one looks at the plugins today, there are already two groups of them: those that one virtually HAS to use in order to do anything with an IDE, and then all the others...

for instance an IDE would likely always offer some compiler. well, that compiler would be a service, the service to be able to compile something. inside the service there would be plugins to specialize the service, for instance being of type gcc or intel compiler, local or distant, etc.

AST would be a general service specialized by plugin for each language. it would be used outside by plugins like CC or refactoring or searching or statistics or symbol browser or whatever.

just thinking. most probably this would be so great a change it is not worth while. not to repeat the netscape experience... by all means.

Navigation

[0] Message Index

[#] Next page

[*] Previous page