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)