Re: plugin plans, -I

On Saturday 14 February 2015, Felix Salfelder wrote:
> - 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.

agreed.

> - 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.

This is one of the reasons for delayed formal release.

I agree, and that was lost with the split build.  Needs to come 
back.  Neither build system really works correctly in this.

> - 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).

so do I.
but I do as much of that as I can with plugins, out of tree.

gnucap-uf is static linked, old pre-split configuration.

Now, lib, main, modelgen, and plugins (apps directory) are 
considered separate, asynchronous.