🚀 go-pugleaf

In article <AJG.92Jul22114544@sp1.ccd.harris.com>, ajg@controls.ccd.harris.com (Arnold Goldberg) writes:
> 
> We here have a very large source tree.
> 
> What I'm looking for is a script or utility that will somehow tell
> me which #include files are not actually needed for a source file.
> 
> any takers???

I did this specifically for BCC++ on (ugh!) MSDOS written in C, so no
code included here. (Would rather have done it in perl :-)

Here's how:

1) for each argument to program (assumed to be name of C file)
2) spawn (?) compile for this program, verifying good compile
	(or go to next file)
3) read and store line numbers of all #include statements.
4) store original copy somewhere
5) make new file by same name with one #include left out (line missing)
	(I started from highest line number to lowest, meant I
	didn't have to adjust line numbers)
6) recompile, checking for compile error
7) if compile error, re-insert #include line, if no error, leave out
8) repeat from 5) for each include...
9) if last compile fails, do one more compile

Assumptions...

a) I have a very consistent organization for all my compiles, they are
all the same, so it's no trouble to figure out how a file is compiled.
This knowledge is built into the include remover. (I don't believe in
custom make files.)

b) I have plenty of time. For 'n' #includes, I actually compile the
file 'n+2' times (I want to leave a good object when I am done).
However, this process doesn't destroy anything, so it could be run
overnight.

c) This still doesn't work all the time. There are cases where an include
file is required for what it defines at link time (compile still works,
link fails), but I think this is bad design and am trying to get the
person responsible to change this design...


This was written to go along with an environment for compiling that
recognized Borland error messages like 'prototype missing for printf'
and automatically inserted #includes (from a preprocessed list), but
because some functions are in more than one include file, generally too
many includes were inserted.  Also, some of us like to write programs
by copying an existing file and changing things (like removing
graphics), so we generally have too many #includes.

Conclusions:

It (mostly) works.
It seems ugly.
-- 
Rick Klement - email:   rick@infoserv.com

#include <standard.disclaimer>
RULE #7: When you can say something in a positive way or a negative way,
         don't say it in the negative way.