Re: [ng-spice] Main headers


To ng-spice@ieee.ing.uniroma1.it
From Arno <A.W.Peters@ieee.org>
Date Fri, 10 Sep 1999 21:22:59 +0200
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
In-Reply-To <37D818E2.25D84CA5@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 >
Reply-To ng-spice@ieee.ing.uniroma1.it
User-Agent Mutt/1.0pre1i

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: