[Distutils] Proposed new Distutils API for compiler flag detection (Issue26689)

[Ralf Gommers]

On Sat, Aug 20, 2016 at 8:33 AM, Ned Deily <nad at python.org> wrote:

> Some months ago, Sylvain brought up a couple of proposals for Distutils.
> The second proposal received some discussion but it appears that the first
> one got lost.  Here it is:
>
> > From sylvain.corlay at gmail.com  Wed May 25 12:01:51 2016
> > From: sylvain.corlay at gmail.com (Sylvain Corlay)
> > Date: Wed, 25 May 2016 12:01:51 -0400
> > Subject: [Distutils] Distutils improvements regarding header installation
> >  and building C extension modules
> > Message-ID: <CAK=Phk4tg_S2mVS2eAkLK514Aq_gq26yEg_vWwAEz8NnstypMg at mail.
> gmail.com>
> >
> > Hello everyone,
> >
> > This is my first post here so, apologies if I am breaking any rules.
> >
> > Lately, I have been filing a few bug reports and patches to distutils on
> > bugs.python.org that all concern the installation and build of C++
> > extensions.
> >
> > *1) The distutils.ccompiler has_flag method.*
> > (http://bugs.python.org/issue26689)
> >
> > When building C++ extension modules that require a certain compiler flag
> > (such as enabling C++11 features), you may want to check if the compiler
> > has such a flag available.
> >
> > I proposed a patch adding a `has_flag` method to ccompiler. It is an
> > equivalent to cmake' s CHECK_CXX_COMPILER_FLAG.
> >
> > The implementation is similar to the one of has_function which by the way
> > has a pending patch by minrk in issue (http://bugs.python.org/issue25544
> ).
>
> On python-dev and in the bug tracker, Sylvain has understandably asked for
> a review with an eye to adding this new feature to Python 3.6 whose feature
> code cutoff is scheduled for a few weeks from now.  As release manager, I
> am not opposed in general to adding new features to Distutils but I think
> we should be very cautious about modifying or adding new Distutils APIs,
> given that many third-party distribution authors want to support their
> packages on multiple versions.  So I want to make sure that there is some
> agreement that adding this new API starting with 3.6 is a good thing to do
> rather than having it go in under the radar.


I'd rather see that kind of thing added to setuptools. We're already having
to deal with setuptools as a moving target, so if distutils becomes one
again as well that means more testing with combinations of different Python
and setuptools versions. Imho distutils changes should be bugfix and
essential maintenance only.


> If there are technical review issues with the implementation, it would
> probably be better to give those directly on the bug tracker.
>

The usual one for disutils: it's a patch with zero tests and zero docs. It
looks pretty safe to add, but still....

Ralf




>
> Opinions?
>
> Thanks!
> --Ned
>
> --
>   Ned Deily
>   nad at python.org -- []
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160821/b316ecaf/attachment-0001.html>