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 _______________________________________________ Gnucap-devel mailing list Gnucap-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gnucap-devel
