Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: MortenMacFly on February 07, 2012, 12:13:40 pm

Title: Compile on demand plugin
Post by: MortenMacFly on February 07, 2012, 12:13:40 pm
I have found a plugin again which I wrote some time ago.
It enables you to let C::B build a file whenever you save it, so that the project is always up-to-date. (It requires a patch on the compiler plugin to work.)

Here it comes... feel free to report if it is of help...
Title: Re: Compile on demand plugin
Post by: ptDev on February 16, 2012, 08:51:29 am
Works as advertised on my local build. :) This is a very interesting plugin indeed. Can I make small changes to it?
Title: Re: Compile on demand plugin
Post by: MortenMacFly on February 16, 2012, 08:54:25 am
Works as advertised on my local build. :) This is a very interesting plugin indeed. Can I make small changes to it?
Sure, but please use the (updated) version I have attached to this post.
Title: Re: Compile on demand plugin
Post by: oBFusCATed on February 16, 2012, 09:38:16 am
I've also wanted to try it, but it was intended to build as part of the contrib plugins, so I didn't bother to fix it to compile off tree.

I don't like the practice of making plugins compile from inside the c::b tree.
We must make sure we provide proper sdk which can be used easily to make plugins for c::b.
Title: Re: Compile on demand plugin
Post by: ptDev on February 16, 2012, 10:12:19 am
Fixing the paths is relatively easy. We can already use the CB variable to allow plugins compilation anywhere.
Title: Re: Compile on demand plugin
Post by: MortenMacFly on February 16, 2012, 10:22:46 am
I don't like the practice of making plugins compile from inside the c::b tree.
As I have in mind to submit it later, I didn't want to change it at that time. ;-)
Title: Re: Compile on demand plugin
Post by: ptDev on March 03, 2012, 12:18:15 pm
I'm trying to make CompileOnDemand add a check item to the Build menu instead of using that single-checkbox dialog to turn it on or off. It just makes more sense IMHO. I made it inherit from cbPlugin instead of cbToolPlugin and added the needed BuildMenu(...) and event handler.

The problem is that it always fails to find the Build menu. Why is this the case? Is it being loaded before the Compiler plugin? Is there a simple way to fix it?

I'm also wondering whether it wouldn't be better to simply add the functionality to the Compiler plugin...
Title: Re: Compile on demand plugin
Post by: MortenMacFly on March 03, 2012, 12:39:05 pm
The problem is that it always fails to find the Build menu. Why is this the case? Is it being loaded before the Compiler plugin?
Yes - that most likely the reason. And keep in mind that in the future it may have way more config options! I don't kn ow if that is such a good idea... (see below).

Is there a simple way to fix it?
You'll need to delay the attachment to the menu.
 
I'm also wondering whether it wouldn't be better to simply add the functionality to the Compiler plugin...
I ad in mind to enhance it step by step: So that in the end it will sit in the background and compile what's needed not only on save.

And btw: As of now it has a serious bug that it interferes with C::B (and makes it hang) if you have modified files open and hit compile. At that time the interim compilation will make C::B hang. Solution: If the build process is started, ignore the events from Compile n demand (or don't send them from the plugin).
Title: Re: Compile on demand plugin
Post by: ptDev on March 03, 2012, 12:52:56 pm
Yes - that most likely the reason. And keep in mind that in the future it may have way more config options! I don't know if that is such a good idea...

I'll keep the options dialog here too, then. On the other hand, how do I delay attaching the menus, if building the plugins menu is called from CodeBlocks through the cbPlugin interface?

Quote
As of now it has a serious bug that it interferes with C::B (and makes it hang) if you have modified files open and hit compile. At that time the interim compilation will make C::B hang. Solution: If the build process is started, ignore the events from Compile n demand (or don't send them from the plugin).

I'll learn if I can check if a compilation is already started and make CompileOnDemand skip the event handler in that case.
Title: Re: Compile on demand plugin
Post by: MortenMacFly on March 03, 2012, 01:34:14 pm
how do I delay attaching the menus, if building the plugins menu is called from CodeBlocks through the cbPlugin interface?
I.e. storing the menu pointers and adjusting the menu after the startup complete event.
Title: Re: Compile on demand plugin
Post by: Jenna on March 03, 2012, 02:22:33 pm
how do I delay attaching the menus, if building the plugins menu is called from CodeBlocks through the cbPlugin interface?
I.e. storing the menu pointers and adjusting the menu after the startup complete event.


Another idea would be to add the possibility to make one plugin depend on another to be loaded.

That would (of course) require changes to the pluginmanager.
Title: Re: Compile on demand plugin
Post by: MortenMacFly on March 03, 2012, 03:16:52 pm
That would (of course) require changes to the pluginmanager.
My idea (a while back) was to have a plugin weight, which can be read from the plugin's manifest file. This way, a user can modify the load order if needed, it should be easy to implement and we can re-use code of the file weight for compilation units.

(I did it similar in another project of mine...)
Title: Re: Compile on demand plugin
Post by: oBFusCATed on March 03, 2012, 06:51:33 pm
Another idea would be to add the possibility to make one plugin depend on another to be loaded.

That would (of course) require changes to the pluginmanager.
+1 here.
Plugin-load-weight sounds like a hack/workaround/hard to maintain feature...
Title: Re: Compile on demand plugin
Post by: MortenMacFly on March 03, 2012, 09:09:11 pm
Another idea would be to add the possibility to make one plugin depend on another to be loaded.
So what would be the base for the comparison then? The plugin's name, a GUID?
Title: Re: Compile on demand plugin
Post by: ptDev on March 03, 2012, 09:39:29 pm
Another idea would be to add the possibility to make one plugin depend on another to be loaded.
So what would be the base for the comparison then? The plugin's name, a GUID?

Would using the plugin's name for this be a bad idea?

One could allow a vector of strings of "dependencies" to be passed to a plugin, and plugin manager would make a check for each plugin being loaded, if all of its dependencies have already been loaded (by finding by name).

EDIT: Actually, scratch that. It's probably better to just list dependencies in the plugin manifest file.
Since most plugins do not need this, the required overhead at startup would actually still be acceptable.
Title: Re: Compile on demand plugin
Post by: oBFusCATed on March 03, 2012, 10:22:26 pm
So what would be the base for the comparison then? The plugin's name, a GUID?
A special identifier not shown in the GUI, so the name of the plugin, can easily be changed.
Listing the dependencies in the manifest sounds good to me.
Title: Re: Compile on demand plugin
Post by: Alpha on March 03, 2012, 11:19:04 pm
One situation to consider is what should the plugin manager do if a dependency cannot be met.  I would suggest that in addition to listing dependencies in the manifest, the dependencies should be marked as optional or required.  The plugin manager could use this to determine if it should cancel loading of the plugin in question, or if it should load it after meeting as many dependencies as it can.
Title: Re: Compile on demand plugin
Post by: MortenMacFly on March 04, 2012, 11:08:06 am
The plugin manager could use this to determine if it should cancel loading of the plugin in question, or if it should load it after meeting as many dependencies as it can.
Well - then it becomes more and more complicated for "just" a simple load-order. Concerning the GUID, we also need a mechanism to provide one "world wide" one, also for closed source plugins. This needs the be encoded into all existing plugins, too. Sorry, but the more I think about this the more I prefer a simple weight - we can introduce this w/o affecting anything we've done already.
Title: Re: Compile on demand plugin
Post by: oBFusCATed on March 04, 2012, 12:20:03 pm
Hm, why do you care about closed sourced plugins, now?
They won't load in newer version of C::B anyway, because the API/ABI is already broken since 10.05.
Also I don't think we need required/optional flags.

BTW: The plugin manager should be rewritten, because currently we read the manifest after we load the dll/so, which is slowwwwwwwwwww. (if I've not mistaken of course)
Title: Re: Compile on demand plugin
Post by: MortenMacFly on March 04, 2012, 01:02:57 pm
Hm, why do you care about closed sourced plugins, now?
Not now, but always. My point is, that we should consider the whole impact of any change we do in that direction. And if that change requires modifying each plugin I prefer a solution which does not.

BTW: The plugin manager should be rewritten, because currently we read the manifest after we load the dll/so, which is slowwwwwwwwwww. (if I've not mistaken of course)
Yes - that's true, but I don't see another way as (i.e.) we need to load the plugin to verify the SDK version it is targeting as setup in the manifest file. So this would indeed need some re-factoring... I'm afraid either ways, probably... ???
Title: Re: Compile on demand plugin
Post by: frithjofh on November 08, 2013, 07:53:53 pm
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
Title: Re: Compile on demand plugin
Post by: oBFusCATed on November 08, 2013, 08:06:18 pm
Patches welcome...
Title: Re: Compile on demand plugin
Post by: frithjofh on November 08, 2013, 08:10:49 pm
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
Title: Re: Compile on demand plugin
Post by: oBFusCATed on November 08, 2013, 09:24:52 pm
I would very much like to know what you think of it too...
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.
Title: Re: Compile on demand plugin
Post by: dmoore on November 10, 2013, 05:01:54 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.

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.
Title: Re: Compile on demand plugin
Post by: oBFusCATed on November 10, 2013, 08:43:24 pm
On linux you can not edit LD_LIBRARY_PATH after the application has started. It is done for security.