Re: Directory restructuring

[John Darrington]

On Thu, Feb 02, 2006 at 05:20:21PM -0800, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     > The procedure usually ends up as:
     >
     > 1.  Remove all -I directives from the Makefiles.
     >
     > 2.  Classify the source files according to some reasonable criteria, and 
put
     >     them into respective sub-directories.   
     >
     > 3.  Put in the whatever -I directives are necessary in order to make
     >     the damn thing build.
     
     #1 and #3 together are going to be kind of painful, because some
     source files need a lot of headers in PSPP.

Yes.  That usually is rather repetitive and boring.
     
     > 4.  Run a script over the Makefiles, to extract the -I directives and
     >     create a diagram of dependencies between directories.  Identify
     >     any dependencies which don't seem to make sense.
     
     This sounds like a good idea but I don't know of a script that
     does this.  It sounds like you've done this before--any pointers?

In that past I've written a quick and dirty custom script just to
extract the information, and compact it into a more concise form.
Then manually draw a dependency diagram.
     
     
     If you're volunteering... okay.  I personally hate
     "organizational" type stuff--I'd much rather write code--which is
     one reason it's been put off so long.
     
     I'd propose that, when you get to someplace you think makes sense
     to some extent (whether it compiles and links or not), you post a
     .tar.gz of it somewhere and we can discuss it.  It's such a pain
     dealing with major changes in a CVS tree that it'd be a shame to
     have to make major changes more than once.

OK.  I'll do that.  Perhaps I could ask then that people hold off from
committing any major changes to CVS over the next few days; one line
changes are fine, but anything more than that perhaps should wait.

          Here are the major components of PSPP in my opinion:

 [:snip:]  
 
There are some minor points I disagree on, but I'll discuss them when
I understand them better.
    
     
     Some files will need to be split to fit this well, e.g. sort.c
     currently implements both the SORT CASES BY command and the
     infrastructure for sorting.  The former should go into the
     "dictionaries and data" directory, the latter into
     "transformations".

Definately.  And there are a number of files (pool.c comes to mind)
that have test functions, and therefore depend upon the lexer and god knows
what else).  The test functions need to be moved to seperate files.
     
     Other files aren't named well and we'd want to change them,
     e.g. I've been a bit irritated with "sfm-read.c" and related
     files for a while.  It should really be something like
     "sysfile-reader.c", because that makes it a lot more obvious what
     it actually does.

I agree.
     
     Let me propose an initial file split to start out, based on that,
     and everyone can criticize it.  I haven't done any file renaming
     in this sample, because then nobody would really be sure what
     each file actually is:

 [:snip:]

I'll use your proposal as a starting point and see what comes of it.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.

signature.asc
Description: Digital signature