Re: [ng-spice] Main headers
Arno wrote:
>
> 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>
> ...
Yes, I agree entirely.
[snip]
>
> 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.
That is not really usefull in our case, unless we want to build an independant
library (libngspice.so for ex) , and even in this case it can easily be done
with one single configure script. Separating the .h files from their
corresponding
.c files makes extra work in the Makefile.am files, which are at present
*very*
simple. Let's not complicate things.
> >
> > 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 :-).
No he doesn't ha ha :-) I made them.
The reason not to include them is to keep tar.gz as small as possible, and
possibly
oriented towards users. The tests are usefull to developpers mostly, and
they'll
work by cvs (unless they are very small in size, in which case it doesn't
matter)
Including them is no real problem.
> > 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?
Good question - I don't know how it is handled, but I don't see any reason why
they should be different. I know this is how ACS works - the netlist is built
dynamically that way.
>
> 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.
I haven't looked in the parser/interpreter code, but I do think this is
how it is done.
Suggestion: here are some directories for a new tree:
parser/
interpreter/
devices/
analysis/
tran/
ac/
dc/ etc... (this was suggested by paolo)
maths/
sparse/
misc/
> As nothing depends on it, we may as well remove it, leaving it in
> CVS's Attic.
yes.
manu
Partial thread listing: