Mailing list archives : pcb-rnd

ID:629
From:ge...@igor2.repo.hu
Date:Sat, 15 Apr 2017 10:15:18 +0200 (CEST)
Subject:[pcb-rnd] trunk: plugin system rewrite
replies: 630 from ge...@igor2.repo.hu
Hi all,
 
I am switching the plugin system from the old implementation to puplug. 
At the end, as an user, you should see no difference, but trunk/ won't 
work properly in the next few hours. I will send another mail when the 
transition is finished.
 
Background:
 
Why we need this now: to have plugin-plugin dependencies; without this 
only way to make sure a dependant code is already in memory by the time we 
load a plugin is to mark the dependant code buildin. This seriously 
restricted the usefulness of the plugin system lately: if you wanted to 
make hid_gtk2_gdk a plugin, lib_gtk* would be marked as buildin, which 
means core still depends on gtk.
 
What you'll get as an user: if you mark something as a plugin, it may 
bring in some more code as plugins, but you don't get tons of builtins. 
This probably doesn't make a big difference when you are compiling from 
source but will make a difference for distro packaging.
 
As a developer: the new system has all plugin info in a single .pup file, 
next to the plugin; no more diplications, no more registration of new 
plugins in 2 different scconfig files. There'll be a new term "conflict"; 
2 conflicting buildins can't be configured; 2 conflicting plugins can not 
be loaded in the same time. Autoload: the old system loads all .so files 
it can find; the new system loads only those that are marked autoloadl; 
this allows us to have more lib plugins that are really loaded only 
on-demand.
 
What the old system is: half part inherited code from mainline, half part 
extensions I made in pcb-rnd.
 
Why can't we keep the old system: it would be code/effort duplication as I 
already solved these problems in libgpmi.
 
What's the new system: puplug, the Portable Micro Plugins. I've split gpmi 
so the plugin part is a separate lib, puplug. I've also extended it a bit 
so it can be easier reused in other projects, like pcb-rnd. It's small 
enough that it is not an external dependency but is imported in src_3rd.
 
Regards,
 
Igor2
 
 
 
 

Reply subtree:
629 [pcb-rnd] trunk: plugin system rewrite from ge...@igor2.repo.hu
  630 Re: [pcb-rnd] trunk: plugin system rewrite from ge...@igor2.repo.hu
    631 Re: [pcb-rnd] trunk: plugin system rewrite from ge...@igor2.repo.hu