Re: [ng-spice] Main headers


To ng-spice@ieee.ing.uniroma1.it
From Manu Rouat <emmanuel.rouat@wanadoo.fr>
Date Sun, 12 Sep 1999 14:24:13 +0200
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
Organization la Guilde
References <37D6CF28.B57F4F4C@wanadoo.fr > <19990909011413.C23398@cgmd83085.chello.nl > <37D818E2.25D84CA5@wanadoo.fr > <19990910212259.A1649@cgmd83085.chello.nl >
Reply-To ng-spice@ieee.ing.uniroma1.it
Sender rouat@war.wanadoo.com

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.


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

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


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


A few explanations/suggestions for new names:

- cp : this basicaly contains the interactive interpreter.
I don't know a good explicit name.
 -fte : front-end - also interactive interpreter. 

- inp : input routines, this is the parser. How about call it 'parser' ?

Basically, inp, cp and fte are the parser and the interpreter.

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

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

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

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. 



manu


Partial thread listing: