From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61937 invoked by alias); 18 Jul 2018 10:03:57 -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 61916 invoked by uid 89); 18 Jul 2018 10:03:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:CAFiYyc1ti, H*i:sk:nX4pGoJ, nope, H*f:sk:nX4pGoJ X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jul 2018 10:03:55 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5283B80D; Wed, 18 Jul 2018 03:03:53 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8982C3F318; Wed, 18 Jul 2018 03:03:52 -0700 (PDT) Subject: Re: [RFC] Adding Python as a possible language and it's usage To: Richard Biener , =?UTF-8?Q?Martin_Li=c5=a1ka?= Cc: GCC Development References: From: "Richard Earnshaw (lists)" Openpgp: preference=signencrypt Message-ID: <5ea8fd56-a890-97c2-ce0d-9d419cf9eb6c@arm.com> Date: Wed, 18 Jul 2018 10:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-07/txt/msg00251.txt.bz2 On 18/07/18 10:51, Richard Biener wrote: > On Tue, Jul 17, 2018 at 2:49 PM Martin Li¨ka wrote: >> >> Hi. >> >> I've recently touched AWK option generate machinery and it's quite unpleasant >> to make any adjustments. My question is simple: can we starting using a scripting >> language like Python and replace usage of the AWK scripts? It's probably question >> for Steering committee, but I would like to see feedback from community. >> >> There are some bulletins why I would like to replace current AWK scripts: >> >> 1) gcc/optc-save-gen.awk is full of copy&pasted code, due to lack of flags type classes multiple >> global variables are created (var_opt_char, var_opt_string, ...) >> >> 2) similar happens in gcc/opth-gen.awk >> >> 3) we do very many regex matches (mainly in gcc/opt-functions.awk), I believe >> we should come up with a structured option format that will make parsing and >> processing much simpler. >> >> 4) we can come up with new sanity checks of options: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81397 >> >> 5) there are various targets that generate *.opt files, one example is ARM: >> gcc/config/arm/parsecpu.awk >> >> where transforms: >> ./gcc/config/arm/arm-cpus.in >> >> I guess having a well-defined structured format for *.opt files will make >> it easier to write generated opt files? >> >> I'm attaching a prototype that can transform optionlist into options-save.c >> that can be compiled and works. >> >> I'm looking forward to a feedback. > > I guess we either need to document python as build requirement in > install.texi then, > it currently has > > @item A POSIX or SVR4 awk > > Necessary for creating some of the generated source files for GCC@. > If in doubt, use a recent GNU awk version, as some of the older ones > are broken. GNU awk version 3.1.5 is known to work. > > alternatively we could handle the generated files like those we still > need flex for: > > @item --enable-generated-files-in-srcdir > Neither the .c and .h files that are generated from Bison and flex nor the > info manuals and man pages that are built from the .texi files are present > in the SVN development tree. When building GCC from that development tree, > or from one of our snapshots, those generated files are placed in your > build directory, which allows for the source to be in a readonly > directory. > > If you configure with @option{--enable-generated-files-in-srcdir} then those > generated files will go into the source directory. This is mainly intended > for generating release or prerelease tarballs of the GCC sources, since it > is not a requirement that the users of source releases to have flex, Bison, > or makeinfo. > > We already conditionally require Perl for building for some targets so I wonder > if using perl would be better ... > > Do we get rid of the AWK build requirement with your changes? > Nope, the Arm port uses AWK for handling the CPU description tables. I chose to use that specifically because it was already relied on for other parts of the build system. Please don't go down the Perl line, though... R. > Richard. > >> Martin