From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27511 invoked by alias); 27 Jul 2018 14:54:04 -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 27496 invoked by uid 89); 27 Jul 2018 14:54:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Obviously, testsuites, indication X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Jul 2018 14:54:02 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id CAD32ACDB; Fri, 27 Jul 2018 14:53:59 +0000 (UTC) Date: Fri, 27 Jul 2018 15:11:00 -0000 From: Michael Matz To: Joseph Myers cc: =?ISO-8859-15?Q?Martin_Li=A8ka?= , GCC Development Subject: Re: [RFC] Adding Python as a possible language and it's usage In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00390.txt.bz2 Hi, On Fri, 27 Jul 2018, Joseph Myers wrote: > I would have expected most concerns to be about builds on non-GNU hosts - > not about builds on GNU/Linux where Python is generally already available > (and differences in Python versions should definitely *not* affect the > generated output, so there should be no increases in the number of > iterations required for any bootstrap cycle to converge). > > We've been having a similar discussion for glibc, both about replacing > uses of perl (optional, but required to build the manual and to run > various tests - python is also already required to run various tests) with > python and about replacing uses of awk (required) with python as well, in > the interests of easier maintainability - and I didn't see any concerns > raised about such a change at all. perl is currently included in the bootstrap set. There's no reason why python couldn't be included as well, but we'd have to make it a limited python (so that the additional builddeps become at least minimal), and that leads to further work (decisions and implementation around the existence of minimal-python and full-python). And of course the build time of the bootstrap cycle lengthens non-trivially. Maybe not by much, but still. I don't know why you didn't get concerns raised during those discussions, it can't mean an indication that everything is fine with going from perl to python when part of non-optional build dependencies. (Optional deps are always fine; we're breaking out those parts, like testsuite, into different packages that aren't then part of the bootstrap cycle). > Obviously if you're bootstrapping core packages and their build > dependencies, use in glibc is more or less equivalent to use in GCC. (But > if build dependencies include those involved in testing, you already have > python as one for glibc, and Tcl for GCC, for example.) Testsuites aren't part of the bootstrap cycle if they would have to enlarge it unduly. Tcl and expect is, though (hmm, I wonder why), as is perl; they all have trivial buildrequires. Ciao, Michael.