From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120373 invoked by alias); 18 Jul 2018 12:50:16 -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 120360 invoked by uid 89); 18 Jul 2018 12:50:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=policies, Community, 2x, upgrades X-HELO: mx.coeval.ca Received: from mx.coeval.ca (HELO mx.coeval.ca) (184.75.211.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jul 2018 12:50:13 +0000 Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx.coeval.ca (Postfix) with ESMTPSA id 34885436058 for ; Wed, 18 Jul 2018 12:50:10 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id w126-v6so8503652oie.7 for ; Wed, 18 Jul 2018 05:50:10 -0700 (PDT) MIME-Version: 1.0 References: <1531911391.18413.114.camel@redhat.com> <20180718120625.GA19628@thyrsus.com> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Wed, 18 Jul 2018 12:50:00 -0000 Message-ID: Subject: Re: [RFC] Adding Python as a possible language and it's usage To: Jonathan Wakely Cc: "Eric S. Raymond" , David Malcolm , Richard Guenther , =?UTF-8?Q?Martin_Li=C5=A1ka?= , "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00258.txt.bz2 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. --joel RTEMS >