From Fedora Project Wiki
(Empty template)
 
(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 -->
= Change Proposal Name <!-- The name of your change proposal --> =
= 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 package can loose a runtime dependency on 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 (%{build_cflags} and friends), unless the package uses nonstandard methods to build the extensions.

Only Python 3.7 (python3) and 3.6 (python36) will be changed.

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)
  • 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)

Release Notes