[Distutils] Proposed new Distutils API for compiler flagdetection (Issue26689)

[Sylvain Corlay]

Regarding compatibility, I have been using this on a variety of platforms
and compilers for some time already.

I think that monkey-patching distutils.ccompiler from setuptools is a dirty
solution and should only be provided as a patch for earlier versions of
python. At the moment, setuptools does little on ccompiler except for a
specific msvc patch regarding locating msvcvarsall.bat.

I understand that it is not a concern with C, but this feature becomes
crucial when building extensions with C++ since new flavors of the language
are emerging every couple of years now. It becomes important to be able to
check and output meaningful error messages when the compiler does not
support C++[11/14/17] features if they are needed for an extension.

Sylvain



On Sun, Aug 28, 2016 at 4:34 PM, Steve Dower <steve.dower at python.org> wrote:

> Some of the core development team will be sprinting full time for the week
> leading up to beta 1, so expect a lot of things to get added then.
>
> My main concern with this is compatibility rather than the interface, but
> as a new feature I think it's best to be only in setuptools. Distutils is
> minimal support for building and as long as it works I don't see any reason
> to change it given the ease of getting alternatives.
>
> Cheers,
> Steve
>
> Top-posted from my Windows Phone
> ------------------------------
> From: Sylvain Corlay <sylvain.corlay at gmail.com>
> Sent: ‎8/‎28/‎2016 3:35
> To: Ralf Gommers <ralf.gommers at gmail.com>
> Cc: DistUtils mailing list <distutils-sig at python.org>
> Subject: Re: [Distutils] Proposed new Distutils API for compiler
> flagdetection (Issue26689)
>
> Hi All,
>
> The beta deadline for new features is approaching dangerously.
>
> I agree with Thomas that being able to require Python 3.6 for a project
> does not appear so distant for me (as soon as it is a Python 3 project
> only).
>
> Any chance to get this through? Checking support for language features
> will be more and more required since new version of the C++ standard are
> becoming more frequent. I understand that it is not an issue for a project
> like numpy, but this is a check I do in every single one of my extension
> projects.
>
> Thanks,
>
> Sylvain
>
> On Thu, Aug 25, 2016 at 6:41 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>> On Mon, Aug 22, 2016 at 6:50 PM, Thomas Kluyver <thomas at kluyver.me.uk>
>> wrote:
>>
>>> There's obviously some cost in code duplication; I haven't looked at the
>>> code in question, so I don't know how bad this is.
>>>
>>
>> This patch is pretty short and understandable, so not bad.
>>
>>
>>> I've run into this argument before when trying to change things in
>>> non-packaging-related parts of the stdlib, and I agree with Sylvain that
>>> it's fundamentally problematic. If we're trying to improve the stdlib,
>>> we're obviously taking a long view, but that's how we ensure the stdlib is
>>> still useful in a few years time. This goes for packaging tools as much as
>>> anything else.
>>>
>>
>> This I don't agree with - packaging is fundamentally different for the
>> reasons Donald gave.
>>
>> Ralf
>>
>>
>>> I already have projects where I'm happy to require Python >=3.4, so
>>> being able to depend on Python 3.6 is not such a distant prospect.
>>>
>>> Thomas
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160828/9c0fdcd7/attachment.html>