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