Ned Deily <n...@acm.org> added the comment:
> This is a little arbitrary, but seems as sensible a value as any other.
> (Or maybe it would be better to have get_config_var('srcdir') == None
> instead.)
'srcdir' is problematic for any installed build. Once "make install" has been
performed, there is no obligation to keep the original source and build dirs
around anymore. For Pythons installed on other machines via a binary
installer, like the python.org OS X ones, some of the paths returned by
sysconfig are not meaningful on the installed machine. For an OS X framework
build, the Makefile and friends are copied into a 'config' directory that is
created within the installed framework. So, with the patch, the contents of
that directory (returned by the patched 'srcdir' value) is:
['Makefile',
'Setup',
'Setup.config',
'Setup.local',
'config.c',
'config.c.in',
'install-sh',
'libpython3.3.a',
'libpython3.3.dylib',
'makesetup',
'python.o']
Is that a meaningful surrogate for the build 'srcdir'?
Beyond that, I don't understand why the patch behavior depends on whether the
srcdir is an absolute path or not. I often use absolute paths to configure a
build. If not in a build directory, 'srcdir' should always return either the
proposed value based on what get_makefile_filename() returns or it should
return None. I don't have a strong opinion at the moment about which. One
factor should be an inspection and running of all of the tests. A quick grep
of Lib/ didn't find many references to 'srcdir'.
One other point: distutils still has its own copy of sysconfig. Strong
consideration should be given to making a similar change there.
----------
nosy: +ned.deily
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15364>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
