Re: [Gnucap-devel] plugin plans, -I

[Felix Salfelder]

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