Re: git repo proposal

On Monday 27 May 2013, Felix Salfelder wrote:
> this should not be mixed up with compiling plugins
> collections or packaging extra stuff. and gnucap should NOT
> implement a build system for plugin packages just to make
> plugin development possible.

agreed.
 
> everybody should be able to provide gnucap-plugins or
> gnucap-plugin packages in whichever way (s)he likes. this
> should not conflict or interfere with either gnucap
> development or the gnucap build system.

Yes .. Some plugins will require configuration.  I want to keep 
the gnucap core free of any other dependencies, but sometimes to 
do something you need a library or something special.  That's 
part of what plugins are for.  We have one already, the geda 
plugin, which uses libgeda.  That's fine in a plugin, but it 
would not be ok to make gnucap dependent on libgeda.

> once, verilog (or something like it) support is up, there
> won't be much movement in c-code device modelling anylonger,
> so the whole compilation mess will reduce to a .v{a,ms} ->
> .so translation facility. probably a program within a
> package like gnucap-adms. this routin could be easily
> wrapped into a 'load' command.

That has already happened.  Nobody serious develops models in C 
any more.  Verilog-A is the standard.

That should be the highest priority.  Model developers NOW are 
doing nearly all their work in Verilog-A.  A model compiler 
generating plugins could make gnucap become a first class model 
development system.


Several cases here ..

load foo.va
load foo.c
load foo.cc
load foo.cpp
load foo (a directory)

I think what to do in all of these is obvious.  A few simple 
rules in a default Makefile is all that is needed.