[Gnucap-devel] plugin plans

[al davis]

planning some changes regarding plugins.

The first has to do with the default plugins.  As of now, the 
plugins loaded by default are gathered into one file gnucap-
default-plugins.so.  I want to change that to instead load a 
directory full of individual plugins,  one per file.  The 
benefit is that then a user will be able to easily add or remove 
just by copying or linking the file.  Any plugin will work, 
including the spice models.

I am thinking of using a two (or more) directory arrangement 
like init.d, apache, and some others, where there might be a 
"plugins-available" which is there but not automatically loaded, 
and a "plugins-enabled", which might contain symlinks.  It may 
make sense to have a search path with a list of directories to 
load.   Comments??

To enable this, there needs to be enhancements to the load 
command to load whole directories.  I am working on this now.

There is an inconsistency with #include in plugin source.  For 
plugins built externally, the include statement needs to say 
#include "gnucap/header.h", but for plugins in apps, it's just 
#include "header.h".  It needs to be the same both places.  It 
may seem to work to say #include "gnucap/header.h" in apps but 
it really doesn't.  "header.h" grabs from the gnucap being 
built, but "gnucap/header.h" grabs the installed one.

Since I don't have a way to test it, I don't know what happens 
with MS-Windows.  At one time, it worked, but I don't know the 
status now.  It should work the same everywhere.

Then I can look at configuration.


After that .. load with compile.  I am looking at code from 
gnucap-uf as a start.

The gnucap-uf code also checks for version matching, which is 
really needed, but doesn't work as it should.  The -uf code 
first loads with dlopen as before, then checks two symbols by 
name.  The reason it doesn't work as it should is that dlopen 
runs the static constructors, which might cause trouble if there 
is a mismatch.  Checking after that is too late.  It needs to be 
checked before dlopen is called.  I tried something based on a 
constructor throwing an exception, but that didn't work either.  
dlopen is C code and does not pass through exceptions properly.  
Also, throwing exceptions from a constructor is a bad idea in 
general.