On Fri, Feb 13, 2015 at 10:46:35PM -0500, al davis wrote: > Plugins are considered user space. Most of the time, compiling > user plugins WILL depend on installed headers. It needs to be > easy. #include <gnucap/header.h> requires no configuration.
no, you still need -I$prefix/include for most prefixes. the prefixes that do not require this often are not writable. > But the installed gnucap (or gnucap.conf) could easily provide > the needed info in a suitably easy way, or provide a script: > > gnucap-compile my-plugin.cc > > gnucap-compile my-plugin.va > > That's really better, because now I don't need to remember > things like -shared and -fPIC, and it solves the problem. some more thoughts - gnucap-compile, yes we need some intermediate anyway (convenience, but also for the load command). i had such a script in early gnucap-adms versions. it is now replaced by an executable makefile (gnucap-adms.mk). this turned out to be much simpler/more practical. gnucap-uf now also installs a makefile (gnucap.mk)... YMMV. - gnucap must work before "make install" is issued. why? testing. the usual workflow (something we should adopt) is - configure; make - make check && make install as a user i wouldn't want to install anything that did not pass tests. packagers wont "install" (in the usual sense) at all, and still should check. during development, testing is a must, and installation is optional. - variants. i have various development versions installed in parallel. gnucap, gnucap-uf, gnucap-uf-testing, gnucap-qucs etc. the headers are in $prefix/include/gnucap-$suffix. hardcoding will break this. (it would be nice if gnucap *did* work without install, but this complicates extensions quite a lot). i hope (some of) this is convincing. thanks felix _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
