From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66054 invoked by alias); 18 Jul 2018 14:46:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 66040 invoked by uid 89); 18 Jul 2018 14:46:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=3.4, HX-Received:sk:h4-v6mr, H*i:sk:64f2d86, H*f:sk:64f2d86 X-HELO: mail-yw0-f181.google.com Received: from mail-yw0-f181.google.com (HELO mail-yw0-f181.google.com) (209.85.161.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jul 2018 14:46:08 +0000 Received: by mail-yw0-f181.google.com with SMTP id 139-v6so1802911ywg.12 for ; Wed, 18 Jul 2018 07:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rsh4my4PduPTepKEE77kxzSAU5mzDSyz/vtqiPz6I6M=; b=XJRgb+H3t5xlDdTvJ+d9qmVrRJBShJICVIWmCo6/erIp7wCT3D615X388r4EpaUA2M F87IwbLAV606PytYoaatFx+Uaq+o/OcxSeO17jknq1Ix4rX/qMjKHOVOiMiHpB1i0J8K Gd/TMPoOJCLnGa9JEFXfCBP8nkmbQlRocYaOFfEo68tkqKie8oQYl9IwvRNxwHKnNN4A git4PuNO8Sufcl3DFdUVHiu2q4xZ9k6PCH2wsx+GB99yS4rurtFTO48ryGrHKEpSdp8K afCo+Wg35gXD6mJMCEDuVFZT3u44wwihsaNz11ZGlUJnPhP0PC+1vqGgWSy5K8zjPHSp AReg== MIME-Version: 1.0 Received: by 2002:a0d:e304:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 07:46:06 -0700 (PDT) In-Reply-To: <64f2d86d-3b46-3ede-4782-9f6d5c4fb704@ubuntu.com> References: <1531911391.18413.114.camel@redhat.com> <20180718120625.GA19628@thyrsus.com> <64f2d86d-3b46-3ede-4782-9f6d5c4fb704@ubuntu.com> From: Janne Blomqvist Date: Wed, 18 Jul 2018 14:46:00 -0000 Message-ID: Subject: Re: [RFC] Adding Python as a possible language and it's usage To: Matthias Klose Cc: gcc mailing list Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00261.txt.bz2 On Wed, Jul 18, 2018 at 5:29 PM, Matthias Klose wrote: > On 18.07.2018 14:49, Joel Sherrill wrote: > > On Wed, Jul 18, 2018, 7:15 AM Jonathan Wakely > wrote: > > > >> On Wed, 18 Jul 2018 at 13:06, Eric S. Raymond wrote: > >>> > >>> Jonathan Wakely : > >>>> On Wed, 18 Jul 2018 at 11:56, David Malcolm wrote: > >>>>> Python 2.6 onwards is broadly compatible with Python 3.*. and is > >> about > >>>>> to be 10 years old. (IIRC it was the system python implementation in > >>>>> RHEL 6). > >>>> > >>>> It is indeed. Without some regular testing with Python 2.6 it could be > >>>> easy to introduce code that doesn't actually work on that old version. > >>>> I did that recently, see PR 86112. > >>>> > >>>> This isn't an objection to using Python (I like it, and anyway I don't > >>>> touch the parts of GCC that you're talking about using it for). Just a > >>>> caution that trying to restrict yourself to a portable subset isn't > >>>> always easy for casual users of a language (also a problem with C++98 > >>>> vs C++11 vs C++14 as I'm sure many GCC devs are aware). > >>> > >>> It's not very difficult to write "polyglot" Python that is indifferent > >>> to which version it runs under. I had to solve this problem for > >>> reposurgeon; techniques documented here... > >> > >> I don't see any mention of avoiding dict comprehensions (not supported > >> until 2.7, so unusable on RHEL6/CentOS6 and SLES 11). > >> > >> I maintain it's easy to unwittingly use a feature (such as dict > >> comprehensions) which works fine on your machine, but aren't supported > >> by all versions you intend to support. Regular testing with the oldest > >> version is needed to prevent that (which was the point I was making). > >> > > > > I think the RTEMS Community may be a good precedence here. RTEMS is > always > > cross compiled and we are as host agnostic as possible. We use as close > to > > the latest release of GCC, binutils, gdb, and newlib as possible. Our > host > > side tools are in a combination of Python and C++. We use Sphinx for > > documentation. > > > > We are careful to use the Python on RHEL 6 as a baseline. You can build > an > > RTEMS environment there. But at least one of the Sphinx pieces requires a > > Python of at least RHEL 7 vintage. > > > > We have a lot of what I will politely call institutional and large > > organization users who have to adhere to strict IT policies. I think > RHEL 7 > > is common but can't swear there is no RHEL 6 out there and because of > that, > > we set the Python 2.x as a minimum. > > > > Yes these are old. And for native new distribution use, it doesn't > matter. > > But for cross and local upgrades, old distributions matter. Particularly > > those targeting enterprise users. And those are glacially slow. > > > > As an aside, it was not being able to build the RTEMS documentation that > > pushed me off RHEL 6 as my primary personal environment last year. I > wanted > > to be using the oldest distribution I thought was in use in our > community. > > doesn't RHEL 6 has overlays for that very reason to install a newer > Python3? > EPEL provides python 3.4 for RHEL6. (EPEL is a non-official add-on repository, but I suspect the vast majority who aren't running some single-task server have it enabled) Don't know if there's something equivalent for SLES. > Please don't start with Python2 anymore. It's discontinued in less than two > years and then you'll have distributions not having Python2 anymore. +1 -- Janne Blomqvist