< Changes
Churchyard (talk | contribs) (Empty template) |
Churchyard (talk | contribs) (Summary) |
||
| Line 21: | Line 21: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= | = Python distutils to use build flags for extension builders (XXX better name?) <!-- The name of your change proposal --> = | ||
== Summary == | == Summary == | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | ||
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". --> | Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". --> | ||
The build flags (<code>CFLAGS</code>, <code>CXXFLAGS</code> and <code>LDFLAGS</code>) saved in the Python's distutils module for building extension modules are switched from <code>%{build_cflags}</code>, <code>%{build_cxxflags}</code> and <code>%{build_ldflags}</code> to <code>%{extension_cflags}</code>, <code>%{extension_cxxflags}</code> and <code>%{extension_ldflags}</code>. | |||
This [https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#support-for-extension-builders currently means] no GCC plugins (such as annobin) are activated and no GCC spec files (<code>-specs=</code> arguments) are used by default when building Python extension modules (e.g. with <code>python3 setup.py build</code>). That also means the {{package|python3-devel}} package can loose a runtime dependency on {{package|redhat-rpm-config}}. | |||
The change mostly affects building extension modules by users, outside of RPM environment. The Python standard library and Fedora's Python 3 RPM packages are still built with the "traditional" set of flags (<code>%{build_cflags}</code> and friends), unless the package uses nonstandard methods to build the extensions. | |||
Only Python 3.7 ({{package|python3}}) and 3.6 ({{package|python36}}) will be changed. | |||
== Owner == | == Owner == | ||
Revision as of 09:51, 4 January 2019
Python distutils to use build flags for extension builders (XXX better name?)
Summary
The build flags (CFLAGS, CXXFLAGS and LDFLAGS) saved in the Python's distutils module for building extension modules are switched from %{build_cflags}, %{build_cxxflags} and %{build_ldflags} to %{extension_cflags}, %{extension_cxxflags} and %{extension_ldflags}.
This currently means no GCC plugins (such as annobin) are activated and no GCC spec files (-specs= arguments) are used by default when building Python extension modules (e.g. with python3 setup.py build). That also means the 
python3-devel
The change mostly affects building extension modules by users, outside of RPM environment. The Python standard library and Fedora's Python 3 RPM packages are still built with the "traditional" set of flags (%{build_cflags} and friends), unless the package uses nonstandard methods to build the extensions.
Only Python 3.7 (
Owner
- Name: Your Name
- Email: <your email address so we can contact you, invite you to meetings, etc.>
- Release notes owner:
Current status
- Targeted release: [[Releases/<number> | Fedora <number> ]]
- Last updated: 2019-01-04
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
Benefit to Fedora
Scope
- Proposal owners:
- Other developers: N/A (not a System Wide Change)
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
N/A (not a System Wide Change)
How To Test
N/A (not a System Wide Change)
User Experience
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
N/A (not a System Wide Change)