Author Topic: Compile on demand plugin  (Read 30518 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Compile on demand plugin
« Reply #15 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Compile on demand plugin
« Reply #16 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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Compile on demand plugin
« Reply #17 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Compile on demand plugin
« Reply #18 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)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Compile on demand plugin
« Reply #19 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... ???
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline frithjofh

  • Regular
  • ***
  • Posts: 376
Re: Compile on demand plugin
« Reply #20 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
architect with some spare time  -  c::b compiled from last svn  -   openSuSE leap x86_64  -  AMD FX-4100

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Compile on demand plugin
« Reply #21 on: November 08, 2013, 08:06:18 pm »
Patches welcome...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline frithjofh

  • Regular
  • ***
  • Posts: 376
Re: Compile on demand plugin
« Reply #22 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
« Last Edit: November 08, 2013, 08:24:20 pm by frithjofh »
architect with some spare time  -  c::b compiled from last svn  -   openSuSE leap x86_64  -  AMD FX-4100

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Compile on demand plugin
« Reply #23 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Compile on demand plugin
« Reply #24 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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Compile on demand plugin
« Reply #25 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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]