This patch allows to specify that C header files are 
part of source files for dependency checking. 
The 'sources' list in Extension instances can be 
simple filenames as before, but they can also be 
SourceFile instances created by

SourceFile("myfile.c", headers=["inc1.h", "inc2.h"]).

Unfortunately not only changes to command.build_ext 
and command.build_clib had to be made, also all the 
ccompiler (sub)classes have to be changed because the 
ccompiler does the actual dependency checking. I 
updated all the ccompiler subclasses except 
mwerkscompiler.py, but only msvccompiler has actually 
been tested.

The argument list which dep_util.newer_pairwise() now 
accepts has changed, the first arg must now be a 
sequence of SourceFile instances. This may be 
problematic, better would IMO be to move this function 
(with a new name?) into ccompiler.

Logged In: YES 
user_id=6380

Why is this priority 7??????

Logged In: YES 
user_id=11105

Fred requested it this way:
http://mail.python.org/pipermail/distutils-sig/2002-
March/002806.html

Logged In: YES 
user_id=3066

Wow!  That's certainly more patch than I'd expected, but the
approach looks about right to me.  I'd like to take another
look at it in a few days (mail me if I don't take action
soon) before we accept, just to make sure I understand it
better.

Thanks!

Logged In: YES 
user_id=11105

This patch has two problems:
- it is too large,
- it breaks custom subclasses of distutils' build command
family. I have two of them in my setup scripts, there are
probably more out in the world.

Here is an idea for a totally different approach:
The checking whether targets needs to be rebuild is done
with  the newer_group() and newer_pairwise() functions in
distutils.dep_util. These methods could scan the
source-files for include directives and user the timestamps
of the include files as well.
This patch would be fairly small.
OTOH, I have no C-source scanner lying around, and also
don't feel to write one.

Logged In: YES 
user_id=11105

Shouldn't holdup any release.

Logged In: YES 
user_id=3066

Assigned to Jeremy since he's dealing with this issue today.

Logged In: YES 
user_id=31392

I think this approach to dependency tracking is too
complicated.  The recent depends argument to Extension
rebuilds everything.  This patch would allow individual .o
files to be rebuilt, but at the expense of complicating the
list of sources too much.

Perhaps a compromise would be to use depends to specify
either a list of global dependencies or a list of per-file
dependencies specified as a pair containing a filename and a
list.

Logged In: YES 
user_id=11105

Jeremy's solution works nicely, and is already implemented.
Closing as works for me.