Re: [ng-spice] Main headers
On Thu, Sep 09, 1999 at 10:30:26PM +0200, Manu Rouat wrote:
>
> move all files of src/bin (main.c etc) into src , same for the headers
> of src/include (assuming these are ngspice.h, struct.h macros.h and
>defines.h)
>
> ==> you get exactly the same structure that you described, except that
>header
> files and source files are in the same directories. Using "" or <> for
>inclusion
> is equivalent too in that case. I don't think duplicating
> the tree structure just for the headers is a good idea.
>
> In fact, pushing the idea a bit further : we could also move all directories
> in src/lib into src - we would the get in src:
>
> ngspice.h
> macros.h etc
> main.c
> multidec.c
> proc2mod.c
> tune.c <== BTW this one should get busted
> etc
>
> ckt/
> cp/
> dev/
> fte/
> hlp/
> inp/
> mfb/
> misc/
> ni/
> sparse/
>
>
> What do you think?
>
> 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.
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.
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.
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.
*drum rolls*
I give you the proposed directory tree.
ng-spice/
include/ # spice data structures, macro's, defines
src/ # contents of src/bin moves here
ngspice.h
struct.h
macros.h
defines.h
tests/ # testing spice, nutmeg, etc functionality
lib/ # contents of src/lib moves here
sparse/
include/ # API for sparse matrix manipulations
src/ # sparse matrix library
doc/ # documentation for this library
tests/ # tests for sparse matrix functionality only
ckt/
include/ # API for interfacing with circuit? library
src/ # the core functionality of the circuit? library
tests/ # tests for ckt functionality only
cp/ # --- anyone, what does this puppy do?
include/
src/
dev/
include/ # generic device interface
src/ # registering devices, etc.
asrc/ # implementation of asrc device
bjt/ # implementation of bjt device
bsim1/
bsim2/
...
tests/ # tests for dynamic device loading
fte/ # math subroutines (_F_ourier _T_ransform _E_?)
include/
src/
hlp/ # help subroutines
include/
src/
inp/ # --- anyone?
include/
src/
mfb/ # --- anyone?
include/
src/
misc/ # --- anyone?
include/
src/
ni/ # --- anyone?
include/
src/
For reasons I explained above, files in an include directory should
have a one to one mapping with the files in the corresponding src
directory. One separate header file implements a `meta' header file.
Higher level files need only include the meta header file of the
library. The source files in the library itself should only include
those files that it really needs.
> Also don't bother about the -I flags , it's all taken care of by automake
> anyway.
This is moot indeed.
Anyway, I'd like to hear what you think about this proposal.
--
Arno
Partial thread listing:
- Re: [ng-spice] Main headers, (continued)
Parameters and libs with spice.
widlok