module compile/install/load infrastructure

Hi Al. Hi list.

On Tue, Mar 27, 2012 at 11:35:20AM -0400, al davis wrote:
> In my own "fork", that I planned to merge back, I have separated 
> out "apps" (potentially plugins) from "lib" (the core that can't 
> be plugins) and "main" (the minimum non-lib to get it started).  
> "include" is also separated.

does 'is also seperated' mean that the source tree has been reorganized?
in any case: i think it only matters where the file are loacated _after_
installation. and how gnucap is supposed to find them.

> Installation should install the "include" files, because they 
> are needed to build plugins.

agreed. but also, the compiler needs to know where they are, the plugin
installer needs to know where to put them, and gnucap/load needs to find
them. i see a certain urge of having this functionality in upstream
gnucap. i'd like to backport (parts of) gnucap-uf to upstream (to
finally quit gnucap-uf), and some of it would become plugins. but also
things like the gschem plugin would be fun to play with, even before a
next upstream release.

i have solved this in gnucap-uf (gnucap-conf script, OPT::libpath), and
i'd like to backport it. for many users this would only make sense if it
gets released. would you agree on a 0.36+dev release? as an alternative
i could patch the debian package only (and talk to the maintainers) but
it totally doesn't seem to be a debian-only issue to me.

how does your "fork" handle this? if the next official release
implements this anyway, i'd like to keep it compatible.

> This is not the final list. There are problems with the build, 
> so it is not "released".

can i help with this? how?

regards
felix