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