Allowing Plugin Interdependency and Improving Plugin Management

[dmoore]

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.

Yes, clearly we are talking past each other. The reason I haven't just "done it" is I am still not sure of the best way to proceed.

The bottom line is that I want to scratch two immediate itches:
1. I had at one time developed a Python Interpreter "console" that would appear in the tools plus dockable and I want to get it working again, but now that Tools+ is part of contrib this is a pain. If I moved the relevant bits of Tools+ into the core, then I just need to expose these bits in the SDK API. Alternatively, I need to figure out some other way for the python interpreter to use that notepage (either (a) link against Tools+ itself or (b) have Tools+ and the Python Interpreter links against a common shared lib a la wxSmith).
2. The rest of my python programs uses some XMLRPC stuff that I want to share across plugins. The common bits take care of all the messy process management and threaded communication using a manager class that there really should only be one of. So again, I either need a shared library approach, a link against plugins approach, or I could do the multiple plugins in a single binary as you propose below.

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.

This isn't a horrible idea. BUT... Do any of our current plugins do this already? I ask because as far as I can tell the PluginManager code doesn't really handle all of the nuances involved in this. e.g. has anyone tried to uninstall or export one of these plugins?
My patch will need to be modified to handle this case as well. e.g. I unload after detaching a plugin, but I should only unload after the last plugin in the bundle has been disabled.

[thomas]

(note: I've only read the first 5 posts)

I find the idea great in general, but it would need to be done with thought and care. Even if it turns out to be really easy, please spend another month or so thinking about it. The reason is that we can't change the way plugins work every few weeks (or we'll get abuse both from plugin writers and from users who have broken setups), so whatever we do, it will be "The Way Plugins Are" for the next couple of months/years. Think twice, then think again. Other than that, great plan.

As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too  ). Are you sure it's problematic? I think it might just work fine.

[oBFusCATed]

As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too  ). Are you sure it's problematic? I think it might just work fine.

dmoore's problem is that he doesn't want to place his so/dll file next to libcodeblocks.so/dll, but this is a requirement at the moment (I've not checked if this is really the case, but I suppose it is).

The visibility flag is something unrelated to this problem. What it will do is to change the defaults to be a bit more sane, aka windows like. This is something that will happen in the future, when I find the time to do it.

dmoore: I've never tried to place two plugins in a single binary, but I've thought it is supported... but I might be wrong.

[dmoore]

please spend another month or so thinking about it.

Roger that.

As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too  ). Are you sure it's problematic? I think it might just work fine.

On windows it should be straightforward because we can add the plugin dirs (user and builtin) to the library path at runtime. On linux,  We can use -rpath to add say /usr/lib/codeblocks/plugins, but I haven't figured out how to add the plugin dir in the users home. It's almost as if the GCC devs think that's a security risk 

[oBFusCATed]

It's almost as if the GCC devs think that's a security risk 

GCC devs have nothing to do here. Its the dynamic linker devs (glibc) that think this way.

[dmoore]

The visibility flag is something unrelated to this problem. What it will do is to change the defaults to be a bit more sane, aka windows like. This is something that will happen in the future, when I find the time to do it.

Maybe this makes my first patch mostly redundant. If using visibility radically improves link time then it doesn't really matter that all libs get loaded.

dmoore: I've never tried to place two plugins in a single binary, but I've thought it is supported... but I might be wrong.

I think it "kinda" works, but I am not sure about how the manifest naming works and I'm pretty sure that export and uninstall won't do the right thing (i.e. export or uninstall everything in the same dll/so)

[oBFusCATed]

Maybe this makes my first patch mostly redundant. If using visibility radically improves link time then it doesn't really matter that all libs get loaded.

I don't think it is related to the load time. The only benefit might be smaller size plugins and of course no more symbol collisions (not really serious problem in c::b).

[dmoore]

As for linking one DLL (a plugin is just a DLL after all) against another DLL under Windows, this is something I've done many times in the past, without doing anything special (I heard of the visibility flag for the fist time too  ). Are you sure it's problematic? I think it might just work fine.

dmoore's problem is that he doesn't want to place his so/dll file next to libcodeblocks.so/dll, but this is a requirement at the moment (I've not checked if this is really the case, but I suppose it is).

Strictly speaking, the so/dll can be placed anywhere that's in the loader's search path. On windows we can change this path at run time, so no big deal. On Linux, -rpath/-rpath-link adds some flexibility, but it means we can never have plugins that are depended on in users home (becasue we don't know where home is at compile time). Maybe that's a limitation we can live with?

[Alpha]

On Linux, -rpath/-rpath-link adds some flexibility, but it means we can never have plugins that are depended on in users home (becasue we don't know where home is at compile time). Maybe that's a limitation we can live with?

I found the following here.  It is not elegant, but it might work if needed.

On UNIXish sytem there is a notion of TMPDIR - if needed, you can first find all the needed libraries, then symlink them to a directory under TMPDIR, then use the the full path with that directory.

[oBFusCATed]

I found the following here.  It is not elegant, but it might work if needed.

Hm, are you really proposing this solution?

[dmoore]

Small update on this. Apparently on some linuxes (e.g. I think YES Fedora, but I think NO for Ubuntu) ~/.local/lib is in the library search path for each user. So this would make it possible to use a cbplugin package deploy a lib shared by multiple plugins into the user space (i.e. no root/admin permissions required). So plugins could still be installed to ~/.codeblocks/share/... but common libs would need to go in ~/.local/lib in order to be found.

As a side note, according to the free desktop standard, C::B should really be using ~/.config and ~/.local for settings and plugin files, so maybe plugins should go somewhere like ~/.local/lib/codeblocks (see http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)

[oBFusCATed]

I've just re-read the topic.
And I really think we should get at least the first part of the patch in trunk.
Does it change anything in the plugins (manifest/api/abi)? If no then it should be relatively safe to apply it. Hopefully it will improve the load time of cb, which is pretty bad at the moment.

[MortenMacFly]

And I really think we should get at least the first part of the patch in trunk.

Probably, but please not the comment in this line:

Code: diff

+    cbPlugin* plugin = FindPluginByName(basename); // THIS DOESN'T WORK RIGHT...

So its not ready yet... Furthermore it should be carefully tested. E.g. is it still possible to enable/disable/enable a plugin.

[dmoore]

It needs to be changed to handle enabling and disabling multiplugin bundles. Off the top of my head, I cannot recall what the issue was with the DOESN'T WORK RIGHT comment.

[ollydbg]

I've just re-read the topic.
And I really think we should get at least the first part of the patch in trunk.
Does it change anything in the plugins (manifest/api/abi)? If no then it should be relatively safe to apply it. Hopefully it will improve the load time of cb, which is pretty bad at the moment.

I agree.

It needs to be changed to handle enabling and disabling multiplugin bundles. Off the top of my head, I cannot recall what the issue was with the DOESN'T WORK RIGHT comment.

I just apply the patch, and I can enable or disable multiply plugins without any issue.
EDIT: I just forget to rebuild the SDK target, sorry, so this is not tested yet, I'm just rebuilding the whole codeblocks_w30.cbp.
EDIT2: After the rebuild, and just tested again, and see no issue here when I enable or disable multiply plugins.