Re: [ng-spice-devel] ACS code


To ng-spice-devel@ieee.ing.uniroma1.it
From Al Davis <aldavis@ieee.org>
Date Fri, 9 Feb 2001 14:31:06 -0800
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <Pine.LNX.3.96.1010208204712.8550A-100000@ieee.ing.uniroma1.it >
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <Pine.LNX.3.96.1010208204712.8550A-100000@ieee.ing.uniroma1.it >
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

On Thu, 08 Feb 2001, Paolo Nenzi wrote:
> On Thu, 8 Feb 2001, Al Davis wrote:
> > On Thu, 08 Feb 2001, Paolo Nenzi wrote:
> > > What about reformat your code (ACS) giving each device a
> > > different dir ?
> >
> > Why?  In most cases, there are two files per device.  In some,
> > only one.  Spice needs the dirs because it has over 20 files per
> > device.
>
> Just to order source files. People who do not use visual
> environments and are approaching your code could find this division
> better IMHO.

I would agree if there were lots of files, like Spice has.  Spice 
would be unmanageable without it.

One change I want to make is for the generated .cc and .h files to be 
located with the .o files.  Then, for the advanced models that use 
the model compiler, there is only one file per device type.  The 
overhead of separate directories in this case is too much and would 
only confuse.

The 20 files per device in Spice are due to bad design, and lack of 
reuse.



> > Actually, I have thought of separating out groups, essentially
> > matching the prefix.  The reason for keeping it flat is to
> > enhance portability.  Considering the tools are better now, it
> > may be time to change.
>
> Why do not adopt the scheme (top level) of ngspice:

That is almost what I mean, but ACS is not Spice so the logical 
separation would be a little different:

device  (d_)
device-base (e_)
analyses (s_)
math (m_)
public (ap_, l_, io_)
acslib (u_)
frontend (c_)

The public and math sections are not ACS specific, so there is value 
in providing them as a library that can be used by other programs.  I 
use the parser class (ap_* files) just about everywhere.  I could 
even license them differently.  The program is GPL, but I would 
consider LGPL or even public domain for the "public" and "math" files.

The main reason for not doing this now has been portability.  Unix 
manages this very well, but some other systems don't.  I think it is 
time to move on, and not worry about the systems that can't handle 
hierarchy.

al.


Partial thread listing: