Re: plugin plans

On Tue, Feb 10, 2015 at 01:24:31AM -0500, al davis wrote:
> 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.

loading directories sounds interesting. why not just include a command
file that attaches the desired ones? like in
$ gnucap
reads user rc (if esists) system rc otherwise. these load plugins.
or just
$ gnucap --rc ~/.gnucap/my_alternative_rc
or similar, to customize....

> 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.

the default header path should be probably $prefix/include/gnucap/*.
that's fine. but you should never depend on *installed* headers.

dont include "gnucap/header.h". use the compiler flags. this way anybody
can put the headers where (s)he wants to. -I/usr/local/include/gnucap
really does not hurt.

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

... it uses the shipped executable "gnucap.mk". might be suboptimal, but
its really flexible.

> 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.

yes, iirc i did not manage to access the library before dlopen. need
something better. one way to get around this is adding an "init()" to
all plugins, which i considered too C-ish, but hey it works :)

cheers
felix