On Tuesday 10 February 2015, Felix Salfelder wrote: > > 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.
What do others think of this? My thoughts .... 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. 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. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
