[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] plugin plans
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] plugin plans |
Date: |
Tue, 10 Feb 2015 09:03:42 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
Re: [Gnucap-devel] plugin plans, al davis, 2015/02/13