home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / programm / 3881 < prev    next >
Encoding:
Text File  |  1992-07-23  |  2.9 KB  |  78 lines
  1. Xref: sparky comp.unix.programmer:3881 comp.unix.questions:9371 comp.lang.c:11550
  2. Path: sparky!uunet!infoserv!rick
  3. From: rick@rick.infoserv.com (Rick Klement)
  4. Newsgroups: comp.unix.programmer,comp.unix.questions,comp.lang.c
  5. Subject: Re: #include file dependancies
  6. Summary: how I did it...
  7. Message-ID: <45.26075@rick.infoserv.com>
  8. Date: 24 Jul 92 04:39:20 GMT
  9. References: <AJG.92Jul22114544@sp1.ccd.harris.com>
  10. Followup-To: comp.lang.c
  11. Distribution: comp
  12. Organization: Rick's Place, San Jose, CA, USA
  13. Lines: 63
  14.  
  15. In article <AJG.92Jul22114544@sp1.ccd.harris.com>, ajg@controls.ccd.harris.com (Arnold Goldberg) writes:
  16. > 
  17. > We here have a very large source tree.
  18. > 
  19. > What I'm looking for is a script or utility that will somehow tell
  20. > me which #include files are not actually needed for a source file.
  21. > 
  22. > any takers???
  23.  
  24. I did this specifically for BCC++ on (ugh!) MSDOS written in C, so no
  25. code included here. (Would rather have done it in perl :-)
  26.  
  27. Here's how:
  28.  
  29. 1) for each argument to program (assumed to be name of C file)
  30. 2) spawn (?) compile for this program, verifying good compile
  31.     (or go to next file)
  32. 3) read and store line numbers of all #include statements.
  33. 4) store original copy somewhere
  34. 5) make new file by same name with one #include left out (line missing)
  35.     (I started from highest line number to lowest, meant I
  36.     didn't have to adjust line numbers)
  37. 6) recompile, checking for compile error
  38. 7) if compile error, re-insert #include line, if no error, leave out
  39. 8) repeat from 5) for each include...
  40. 9) if last compile fails, do one more compile
  41.  
  42. Assumptions...
  43.  
  44. a) I have a very consistent organization for all my compiles, they are
  45. all the same, so it's no trouble to figure out how a file is compiled.
  46. This knowledge is built into the include remover. (I don't believe in
  47. custom make files.)
  48.  
  49. b) I have plenty of time. For 'n' #includes, I actually compile the
  50. file 'n+2' times (I want to leave a good object when I am done).
  51. However, this process doesn't destroy anything, so it could be run
  52. overnight.
  53.  
  54. c) This still doesn't work all the time. There are cases where an include
  55. file is required for what it defines at link time (compile still works,
  56. link fails), but I think this is bad design and am trying to get the
  57. person responsible to change this design...
  58.  
  59.  
  60. This was written to go along with an environment for compiling that
  61. recognized Borland error messages like 'prototype missing for printf'
  62. and automatically inserted #includes (from a preprocessed list), but
  63. because some functions are in more than one include file, generally too
  64. many includes were inserted.  Also, some of us like to write programs
  65. by copying an existing file and changing things (like removing
  66. graphics), so we generally have too many #includes.
  67.  
  68. Conclusions:
  69.  
  70. It (mostly) works.
  71. It seems ugly.
  72. -- 
  73. Rick Klement - email:   rick@infoserv.com
  74.  
  75. #include <standard.disclaimer>
  76. RULE #7: When you can say something in a positive way or a negative way,
  77.          don't say it in the negative way.
  78.