Re: [ng-spice] Main headers


To ng-spice@ieee.ing.uniroma1.it
From Arno <A.W.Peters@ieee.org>
Date Tue, 14 Sep 1999 00:16:56 +0200
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
In-Reply-To <37DB9B6D.2EC3BF8A@wanadoo.fr >
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
References <37D6CF28.B57F4F4C@wanadoo.fr > <19990909011413.C23398@cgmd83085.chello.nl > <37D818E2.25D84CA5@wanadoo.fr > <19990910212259.A1649@cgmd83085.chello.nl > <37DB9B6D.2EC3BF8A@wanadoo.fr >
Reply-To ng-spice@ieee.ing.uniroma1.it
User-Agent Mutt/1.0pre1i

On Sun, Sep 12, 1999 at 02:24:13PM +0200, Manu Rouat wrote:
> Arno wrote:
> 
> > > Now another question is: should we make one header files for each 
>directory
> > > (like ckt.h in src/lib/ckt) or one header file per source file (like in
> > > src/lib/fte) ? I'm more in favour for one file, makes less files to 
>carry
> > > around .
> > 
> > And once you change one function call in that one file, you force the
> > recompilation of the *whole* library because of the dependencies on
> > that one file.  On a big source tree like ng-spice, I'd rather not.
> 
> Hum, yes , correct, I overlooked that one. One header file per
> source file then.  One question: if we have one top ngspice.h file
> (#included by all source files) that #includes all .h files - what
> happens if one of those headers is modified?  Does everything get
> rebuilt? If that very large ngspice.h file creates unwanted
> dependancies, then it is not useful,but I don't know if it is the
> case.

The file ngspice.h should not include the header files from the
libraries.  It should only contain the functions/definitions needed to 
glue it all together.  This eliminates also the recompile problem
mentioned above.

The main ngspice.c should start with something like

#include "ngspice.h"
#include <fte/fte.h>
#include <ni/ni.h>
#include <ckt/ckt.h>
...

You get the idea.  Header files should not include each other, except
for the meta header file for each library.  What is to become a
library is still open for discussion but 


> > I still would like to see interface (API) separated from source.
> > However, I see now that it would be better to do this inside the
> > library subdirectories.  See proposed tree below.
> 
> I'd rather have them not separated, because it makes automake/autoconf
> maintenance easier.

automake/autoconf maintenance can be pushed into the library
directories.  This is reminiscent of how the source to mnemonic is
organized (http://www.mnemonic.org/).  GGI, although these consist
mostly of libraries, (http://www.ggi-project.org/) is another example
of where this organization is in use.

The top level configure script descends into each library.  It calls
the local configure script to use the top level cache.  Maintenance of 
the automake/autoconf scripts should now be limited to each library
separately.

> > Functionality tests should try to focus on the smallest component
> > possible.  Therefore I have added a tests directory to every library.
> > The tests would only need the header files and a binary image of the
> > library.
> 
> I suggest that we don't include them in the distributions, though. only
> in CVS.

Why?  Personally, I see more compelling reasons to include them than
to exclude them.  Besides, Paolo has the last say in this: he makes
the snapshots :-).

> > Also, the current names of the libraries currently don't convey much
> > of the functionality they provide.  Perhaps we should try to find
> > proper names or reorganize source files so functionality gets grouped
> > together.
> 
> Actually, the more I look at the source tree, the more I think that
> this is the main problem - in fact, all those header files in
> include/ wouldn't be a problem if the tree in itself had a better
> organization.
> 
> I've had a look at a few 'large' source trees (wine and linux) and
> both have one quite large include/ directory , plus a few header
> files (but not many) scattered across the sourec tree. These header
> files contain only local declarations etc. All the rest is in the
> include/ directory. They don't even have a one-to-one mapping. I
> don't know what the best solution is.

There are no `best' solutions, only progressively better ones.  Having
said that, it may be useful to summarize the current discussion so we
can focus on the issues that remain.  See also further down.

> A few explanations/suggestions for new names:
> 
> - cp : this basicaly contains the interactive interpreter.
> I don't know a good explicit name.

`cp' could be the abbreviation of `circuit pr(epr)ocessor'

>  -fte : front-end - also interactive interpreter. 

Do we need to make a distinction between an interactive interpreter
and a batch processing simulator?  How is this currently handled in
the source?

How do you like the following idea: can we make the interpreter a
front-end that generates netlists and simulation options on the fly.
It puts interactively entered commands into a dynamically generated
netlist file, sends it off to the batch processor and collects the
results afterwards.

Name suggestion: parts of cp/, fte/ --> interpreter/

Name suggestion: parts of cp/, fte/ --> simulator/ or spice/

> 
> - inp : input routines, this is the parser. How about call it 'parser' ?
> 
> Basically, inp, cp and fte are the parser and the interpreter.

Name suggestion: inp --> parser/

> 
> - mfb is a graphical library - it is useless, we use X11 directly (mfb is
> not included in the tar.gz distribution)

As nothing depends on it, we may as well remove it, leaving it in
CVS's Attic.

> - ni : math subroutines - note that there are also many math
> routines in fte (what the heck are they doing there??)

The Gnu Scientific Libary (http://sourceware.cygnus.com/gsl/) may be
interesting to use as replacement to the math routines currently in
use.  It includes some interesting subroutines for fourier
transformations, random number generators, monte carlo intergration,
vector and matrix manipulations.  It is GPLed.  Perhaps for use in a
GPL only simulator.

Name suggestion: parts of ni/, fte/ --> math/

> - ckt : analysis code - dc,ac , tran analysis etc.

Suggested name: ckt/ --> analysis/

> As you can see, this is all very confusing - and this needs to be
> reworked.  We might have to rebuild an entire source tree from
> scratch up (with the same code of course, but organised a bit
> diffrently). It could be easier than working in this mess.

While I understand your sentiment, in general I find that it is much
easier to take smaller steps and go from working revision to working
revision than to start a massive reworking of the source and only much
later worry if it might compile/run.

Currently, we are discussing the structure of the tree as we think it
should look.  After we agree on the architecture, we have to start
working toward this goal.  Improve a small bit of code here,
reorganize some files there but always with the long term goal in
mind.  After each iteration, take a snapshot and announce it on
freshmeat.net and other similar sites.

I'll be happy to summarize the ongoing discussion into a design
document this weekend.  Once we agree on the details, it can serve as
a guideline to development.

-- 
Arno

Partial thread listing: