| msg190182 - (view) |
Author: Ned Deily (ned.deily) *  |
Date: 2013-05-28 09:27 |
| As part of the initial changes for Issue13590 in 2.7.3, 3.2.3, and 3.3 (prior to release) to Distutils to support building extension modules on OS X with Xcode 4, code was added to substitute the clang compiler if the older gcc-4.2 supplied with Xcode 3 was not found. In addition, the changes made it easier for the user to override the compiler for both the compile and linking stages: "Also as a convenience, if the user does explicitly set CC, substitute its value as the default compiler in the Distutils LDSHARED configuration variable for OS X." This eliminated the need to construct a complete LDSHARED value. For 2.7.4, 3.2.4, and 3.3.0, more extensive changes were made to fully support the latest releases of Xcode 4. Unfortunately, the code to override LDSHARED if CC is set was inadvertently deleted for these later releases. The attached patch restores the deleted override behavior and adds tests. |
|
|
| msg190197 - (view) |
Author: Ronald Oussoren (ronaldoussoren) * |
Date: 2013-05-28 11:45 |
| LGTM |
|
|
| msg190258 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-05-28 23:45 |
| New changeset ca24bc6a5a4b by Ned Deily in branch '2.7': Issue #18080: When building a C extension module on OS X, if the compiler http://hg.python.org/cpython/rev/ca24bc6a5a4b New changeset 75432fb6b9af by Ned Deily in branch '3.3': Issue #18080: When building a C extension module on OS X, if the compiler http://hg.python.org/cpython/rev/75432fb6b9af New changeset 0512bb1b5b8a by Ned Deily in branch 'default': Issue #18080: merge from 3.3 http://hg.python.org/cpython/rev/0512bb1b5b8a |
|
|
| msg190259 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2013-05-28 23:48 |
| Committed for release with 2.7.6 and 3.3.3. |
|
|
| msg372829 - (view) |
Author: Jason R. Coombs (jaraco) * |
Date: 2020-07-02 08:56 |
| In [pypa/distutils#1](https://github.com/pypa/distutils/pull/1), I learned that the test doesn't have the intended effect. Patching `get_config_var()` has no effect because the function under test calls `get_config_vars()`. In some environments, such as PyPy3 as built on Homebrew, the first test fails. |
|
|
| msg372831 - (view) |
Author: Jason R. Coombs (jaraco) * |
Date: 2020-07-02 09:09 |
| For easy reference, the relevant commit is https://github.com/python/cpython/commit/97345680dc. |
|
|
| msg372843 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2020-07-02 10:49 |
| Jason, what action(s) are you expecting with regard to this and by whom? This issue has been long closed. |
|
|
| msg373004 - (view) |
Author: Jason R. Coombs (jaraco) * |
Date: 2020-07-04 23:57 |
| Well, the issue is potentially ignorable, especially if distutils is deprecated and removed from CPython. Alternately, CPython could adopt the [patch from distutils](https://github.com/pypa/distutils/pull/1/commits/c3a052aefbba0d5fda10790e676223c0dc12f0ed) that corrects the issue. Would you like me to file a separate bug for this issue? Or apply that patch? Or something else? |
|
|
| msg373092 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2020-07-06 11:00 |
| > Would you like me to file a separate bug for this issue? Or apply that patch? Or something else? OK, if I understand correctly, the problem you describe does not affect cPython because cPython's Distutils does not use get_config_vars(), only get_config_var(); but other implementation's ports of Distutils may have diverged to use get_config_vars and so the test may fail when running under those implementations using setuptools with its newly cloned version of cPython Distutils. If that is the case, I think it's fine to backport the fix to cPython tests in the interest of minimizing differences. Since it is minor and not really user visible, if you're willing to do so, I'm OK with a PR under this bpo and I don't think a NEWS blurb is necessary. Thanks for bringing it up. |
|
|