Re: Weeding out unwanted include files

!I want to develop a tool that finds out which include files are
!useless, so as to reduce compile time.


nandu@cs.clemson.edu writes:
> Rather than work at the high level of weeding out header files, you could
> attempt to only retain those definitions and prototypes from header files
> that are required in the program.


I think you missed the point of the tool. By eliminating useless header
files, the compiler not only doesn't have to process the text of the
header files, you can often avoid unnecessary recompilations due to a
change in one of those header files. I would find that a much more useful
advantage.


> If file a.c includes math.h and never uses the enumerated
> type fp_pi_type, the compiler would probably weed out the declaration.
> But, what if b.c declares a variable as follows?
>
> extern enum fp_pi_type my_fp_pi;


Huh? If b.c declares such a variable, then *it* must also include math.h.
It doesn't matter what a.c includes.


> If you construct use-def chains, those chains that lack a definition would
> probably trigger your definition-searcher. However, to solve the problem
> described above, you probably can not weed out anything until link time.


Don't understand this comment.


> I don't really see how you can reduce the compilation time. Object code
> size, probably, since you will not carry unwanted information. The search
> for definitions has to be performed each time a file is compiled since you
> never know if any changes result in including some definitions that were
> previously not required.


Don't understand this either. A tool that tells me "header file math.h is
not used in source file a.c" would allow me, if I choose, to remove the
#include. If I subsequently add something to a.c that requires math.h, I
can put the #include back in -- if I don't, I'll get a compilation error.


A caution, though: Such a tool would, ideally, be smart enough to handle
nested include files "properly". For example, if a.c includes file1.h, and
file1.h includes file2.h, then the tool should keep track of whether
anything from file1.h requires declarations from file2.h, and whether
anything in a.c requires declarations from file1.h. Otherwise, I could
get messages about file2.h not being needed in a.c, when a.c doesn't directly
include file2.h; then I have to go *find* where the actual include directive
resides.


Another thing: the tool should be able to deal with the more common
mechanisms used to avoid the problem of multiple inclusion. That is, if
file1.h includes file2.h, and file3.h also includes file2.h, and a.c
includes both file1.h and file3.h, file2.h gets processed twice. Since
that would usually result in compilation errors, most users use ifdefs or
pragmas to avoid including the actual body of file2.h if it has already
been processed.


What this means to an include-file-eliminator is this: It needs to realize
that file3.h depends on file2.h, even though no declarations from file2.h
were processed during the inclusion of file3.h. It would also be helpful
if it could tell that file4.h depended on definitions from file2.h, even
though it didn't include it, so that it could issue messages like:


"File file1.h does not need to include file2.h."
"File file4.h should include file2.h but does not."
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.csd.harris.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.