absolute paths cause problems for MSVC

[eaj]

BPO	827386
Nosy	@loewis
Files	patch.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2005-08-07.20:52:02.000>
created_at = <Date 2003-10-21.09:11:04.000>
labels = ['library']
title = 'absolute paths cause problems for MSVC'
updated_at = <Date 2005-08-07.20:52:02.000>
user = 'https://bugs.python.org/eaj'

bugs.python.org fields:

activity = <Date 2005-08-07.20:52:02.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Distutils']
creation = <Date 2003-10-21.09:11:04.000>
creator = 'eaj'
dependencies = []
files = ['5650']
hgrepos = []
issue_num = 827386
keywords = ['patch']
message_count = 3.0
messages = ['44810', '44811', '44812']
nosy_count = 3.0
nosy_names = ['loewis', 'mdehoon', 'eaj']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue827386'
versions = []

[eaj]

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.

[mdehoon]

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.

[loewis]

Logged In: YES
user_id=21627

The original problem was apparently bpo-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