On Fri, Aug 5, 2016 at 8:02 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 6 August 2016 at 12:15, Steve Dower <steve.dower@python.org> wrote:
FYI, it's MSVC 14.0 (which is included in VS 2015).
Personally I'd like to see it restricted to the common subset of C99 and some version of C++ (which is obviously mostly C and includes no C++), because I know there are a few things in C99 only that are very obscure because they aren't also in C++.
As a pragmatic requirement, what if we went with:
- must compile with the Python 3.5 Windows compiler (so MSVC 14.0) - must compile with the Python 3.5 Mac OS X compiler (some version of clang?) - must compile with the manylinux1 gcc compiler (gcc 4.8.2, as per PEP 513)
The reason I like the pragmatic definition is that it's one we can readily automate by ensuring these 3 configurations are always present in the stable buildbot fleet, while the formal standards based version is technically more precise, but not in a way we can easily test.
This approach makes a lot of sense to me. In particular it seems like it can avoid getting bogged down in a lot of questions about the theoretical idea of C99, which is often somewhat unclear. I wrote a little test file for all the C99 features that were mentioned in this thread (I think): https://gist.github.com/njsmith/f666671de31f35644bb91a815c9cad75 Ned reports that our OS X compiler is currently GCC 4.2, and that this doesn't officially support "C99" -- but I just checked and it happily builds that file :-). (Judging from [1], it looks like the major feature missing in 4.2 was support for C99's more obscure inlining semantics; but I think we only really care about 'static inline' specifically, and that appears to be unchanged [2].)
Phrasing the policy that way would mean moving future iterations of the manylinux spec out of distutils-sig only territory into one which needs to be reviewed by both distutils-sig and python-dev (since it would now also modify CPython's compiler compatibility requirements in PEP 7), but I think that's a reasonable position to adopt, and unlikely to cause any major problems (manylinux is a *trailing* edge definition that is only likely to get updated as the oldest enterprise Linux definitions drop out of commercial support)
With my manylinux maintainer hat on, I don't think there'd be any problem with bringing python-dev into those discussions. But note that technically, the manylinux1 spec doesn't say what compiler you can use; it says that whatever compiler you use has to generate binaries that work on CentOS 5. (Why CentOS 5? Because it's the oldest non-EOL linux distribution in common use; manylinux2 will presumably bump the requirement to CentOS 6 once CentOS 5 goes EOL). The reason this matters is that the official vendor compiler on RHEL 5 is gcc 4.1, but there's also a separately-distributed version of gcc 4.8.2 that can target it. If a packager trying to build manylinux wheels wants a more modern gcc, then it's reasonable to ask them to get this patched gcc. But for an end-user who's just trying to build CPython on their machine, you might or might not consider this an acceptable request -- maybe CPython wants to work on default vendor compiler to imposing that on users. And in practice this almost certainly doesn't matter -- the only reason people jump through hoops to get gcc 4.8 is for its improved C++ support. I just tried my c99 test file on CentOS 5's default gcc 4.1 and it was fine. And since RHEL 5 is going EOL in March 2017, for 3.6 purposes we only care about RHEL 6+, which ships with gcc 4.4, which is even less of a worry. tl;dr: for purposes of 3.6 on linux, "CPython has to build on gcc 4.4" should be a fine rule that works for everyone. But I guess we probably also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases. -n [1] https://gcc.gnu.org/c99status.html [2] "The [different versions] of inlining behave similarly ... when the inline keyword is used on a static function" -- https://gcc.gnu.org/onlinedocs/gcc/Inline.html -- Nathaniel J. Smith -- https://vorpus.org