When source files are given in the form:

c:\foo\bar.c

the object file is written to:

c:\foo\bar.o

instead of the build\temp.win32-2.3 directory.  This is 
because the object_filenames method doesn't chop off 
the drive name from source file name base before trying 
to concatenate the build directory with the base.  This 
results in the build directory being ignored.  The 
ccompiler.py object_filenames does it right, so I just 
copied its behavior.  

Logged In: YES 
user_id=488897

I have tested your patch and found that it works as intended.
I am a bit surprised about the approach taken in ccompiler.py:
1) Using absolute paths is not portable, so I'm not sure why
somebody would want to do that.
2) With this patch, If the source file is in c:\foo\bar.c,
then the object file is written to
build\temp.win32-2.3\Release\foo\bar.o. However, if the
source file is written with a relative patch ("bar.c"), the
object file is written to build\temp.win32-2.3\Release\bar.o
(so without "foo"). Hence, even though the source file bar.c
is in the exact same location in these two cases, the object
file ends up in a different location depending on whether
the path is specified as absolute or relative. Is that
really what we want?

But I agree that the behavior of msvccompiler.py and
ccompiler.py should be consistent.

Logged In: YES 
user_id=21627

The original problem was apparently #668662, which caused
the introduction of support for absolute paths in
ccompiler.py. It's not clear in that report why anybody
would use absolute paths in setup.py, but apparently, f2py
would generate setup files that use absolute paths.

Integrating the entire path into the Release directory is
intentional, since the same source file name may occur
multiple times for the same project (in different directories).

Thanks for the patch and the review, committed as

msvccompiler.py 1.64.2.4
NEWS 1.1193.2.69
msvccompiler.py 1.69
NEWS 1.1330