Reducing the header maze (warning: long, unsuitable for children)

[Greg Turner]

I'm working on Ove's comhdr1 & comhdr2 patches.

So far, so good, btw -- I have it compiling against yesterday's CVS 
(recent commits are not folded in yet).  I'll submit after I kick the 
tires a bit and make sure everything seems to be working (otherwise, 
I'll probably post it here and ask for help).

Anyhow, this project has served to remind me just how deep, and how 
confusing, the maze of wine headers can really be.  It's clear to me 
that lots of header inclusions are just historical remnants, that no 
longer serve any purpose, and, conversely, that many implicit header 
dependencies exist that happen to be hidden, and missing (i.e., X.h 
needs Y.h, but all references to X.h happen to occur after Y.h was 
already included, so there's no compile failure).  A third kind of 
unnecessary (but arguably correct, in many cases) dependency is created 
when an include file is pulled in that is already pulled in by some 
prior include...

This negatively affects wine development because (a) it's hard to change 
things, the headers break too easily, and (b) the make process rebuilds 
stuff that doesn't need rebuilding when things change (unavoidable, to 
an extent, of course, but perhaps it's too much right now).

Now, here's my question: couldn't we build a script to automatically fix 
some of these problems?  Imagine this pseudocode as a bash script, 
makefile, or something along those lines:

o gather and create a table of all .c -> .h and .h -> .h dependencies

o for each file:
  o one by one, try removing each reference to a header, and see if the
    affected units still compile.  If they all do, permanently
    remove that reference, but remember it was there

at this point we should have approximately the minimum number of header 
references in the code to compile wine.  But some of the header 
references we eliminated were probably legitimate dependencies,
event though we compiled OK, as mentioned above... so now we:

o for each header, try to compile a "Hello World" which includes just 
that header file.  If it fails (or even generates warnings):
  o for each header reference that was eliminated, try putting it back
    in.  If still failing, try different combinations (this
    could become a really nasty computation with all kinds of
    permutations possible, but if certain simple tricks don't work, we
    can just give up).
  o if we couldn't find any way to fix it, mark the header for human
    review.

This should ensure that each header can actually be run through the 
compiler all by itself -- that is, that it #include's any headers it 
relies on to compile.  Finally...

o A human picks up the pieces and fixes the breakages

o The whole heuristic can start over, now, until the results start to
  look repetitive or trivial...

I can think of some reasons this might not work out so well as I might 
hope, but... what do you guys think?  is such a test meaningful?  Is 
there some tool that already automates this type of investigation, or 
some better way to achieve the same thing?  Would it be, in your 
opinion, too much work for too little benefit?

FWIW, I can probably think of more enjoyable tasks to spend my time 
on... but OTOH I am really tired of waiting for wine to build on my 
aging pc -- anything that could speed up the build process would 
probably save me some from some discomfort, and others too.  

(At least there's no C++ in there; I'm rebuilding my system lately (I 
killed it over the holidays messing with glibc), and building stuff 
like KDE, mozilla, sun-java, and openoffice makes wine look pretty darn 
svelte!  g++ 3.2.1 just crawls; the more "object oriented" the source 
is, the longer it seems to take to compile... :( )

Just "thinking out loud," probably a terrible idea, but let me know what 
you think, anyways...

-- 
gmt

p.s., I was kidding about unsuitable for children... but then, not sure 
why children should want to read this -- or adults, for that matter :P