[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Changes to configure.ac, auto-detection and related build issues

On May 15, 2018, at 01:58, Eitan Adler <lists at eitanadler.com> wrote:
> On Monday, 14 May 2018, Victor Stinner <vstinner at redhat.com> wrote:
> Hi Eitan,
> 2018-05-15 0:01 GMT-04:00 Eitan Adler <lists at eitanadler.com>:
> > I am working on updating, fixing, or otherwise changing python's
> > configure.ac. This work is complex, (...)
> Is your work public? Is there an open issue on bugs.python.org or an
> open pull request?
> I'm opening bugs and PRs as I Go. Some examples are:
> https://github.com/python/cpython/commit/98929b545e86e7c7296c912d8f34e8e8d3fd6439
> https://github.com/python/cpython/pull/6845
> https://github.com/python/cpython/pull/6848
> https://github.com/python/cpython/pull/6849
> https://bugs.python.org/issue33485
> And so on
> If not, would you mind to at least describe the changes that you plan to do?
> > Please feel free to tag me in
> > related PRs or bugs or emails over the next few weeks.
> Hopefully, we only rarely need to modify configure.ac
> I'm primarily worried about breaking arcane platforms I don't have direct access to. 

Hi, Eitan!

As you recognize, it is always a bit dangerous to modify configure.ac and friends as we do support so many platforms and configuration and downstream users try combinations that we don't claim to test or support.  So, we try to be conservative about making changes there and do so only with good reason.

So far, it's somewhat difficult for me to understand what you are trying to accomplish with the changes you've noted so far other than various cosmetic cleanups.  It is also difficult to properly review a bunch of small PRs that modify the same configuration files and especially without an overall tracking issue.  For most of this to move forward, I think you should create or adapt at least one b.p.o issue to describe what changes you are suggesting and why and how they apply to our various platforms and then consolidate PRs under that PR.  Don't be surprised if the PRs don't get much attention right away as we're busy at the moment trying to get 3.7.0 out the door.  And it would be best to avoid including generated files (like configure vs configure.ac) in new PRs as that will only add to the likelihood of merge conflicts and review complexity.


  Ned Deily
  nad at python.org -- []