[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] git repo proposal

From: al davis
Subject: Re: [Gnucap-devel] git repo proposal
Date: Mon, 27 May 2013 02:20:39 -0400
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]