public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: "Martin Liška" <mliska@suse.cz>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: [RFC] Adding Python as a possible language and it's usage
Date: Wed, 18 Jul 2018 09:51:00 -0000	[thread overview]
Message-ID: <CAFiYyc1ti+nX4pGoJQkPXVeVijNsZgwYviEJaeNTC4FJ4hxpHg@mail.gmail.com> (raw)
In-Reply-To: <a9d62363-4a0f-88f6-2346-4dcb3bebfaa5@suse.cz>

On Tue, Jul 17, 2018 at 2:49 PM Martin Liška <mliska@suse.cz> 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?

Richard.

> Martin

  parent reply	other threads:[~2018-07-18  9:51 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17 12:49 Martin Liška
2018-07-18  1:01 ` David Malcolm
2018-07-19 20:24   ` Karsten Merker
2018-07-20 10:02     ` Matthias Klose
2018-07-20 10:07     ` Martin Liška
2018-07-18  9:51 ` Richard Biener [this message]
2018-07-18 10:03   ` Richard Earnshaw (lists)
2018-07-18 10:56   ` David Malcolm
2018-07-18 11:08     ` Jakub Jelinek
2018-07-18 11:31     ` Jonathan Wakely
2018-07-18 12:06       ` Eric S. Raymond
2018-07-18 12:15         ` Jonathan Wakely
2018-07-18 12:50           ` Joel Sherrill
2018-07-18 14:29             ` Matthias Klose
2018-07-18 14:46               ` Janne Blomqvist
2018-07-20 10:01               ` Martin Liška
2018-07-20 16:54                 ` Segher Boessenkool
2018-07-20 17:12                   ` Paul Koning
2018-07-20 17:59                     ` Segher Boessenkool
2018-07-20 18:59                       ` Konovalov, Vadim
2018-07-20 20:09                         ` Matthias Klose
2018-07-20 20:15                           ` Konovalov, Vadim
2018-07-18 21:28           ` Eric S. Raymond
2018-07-23 14:31     ` Joseph Myers
2018-07-18 22:42   ` Segher Boessenkool
2018-07-19 12:28     ` Florian Weimer
2018-07-19 20:08       ` Richard Earnshaw (lists)
2018-07-20  9:49         ` Michael Clark
2018-07-19 15:56     ` Jeff Law
2018-07-19 16:12       ` Eric Gallager
2018-07-20 10:05       ` Martin Liška
2018-07-18 15:13 ` Boris Kolpackov
2018-07-18 16:56   ` Paul Koning
2018-07-18 17:29     ` Boris Kolpackov
2018-07-18 17:44       ` Paul Koning
2018-07-18 18:11         ` Matthias Klose
2018-07-20 11:04           ` Martin Liška
2018-07-19 14:47     ` Konovalov, Vadim
2018-07-23 14:21 ` Joseph Myers
2018-07-27 14:31 ` Michael Matz
2018-07-27 14:38   ` Michael Matz
2018-07-28  3:01     ` Matthias Klose
2018-07-27 14:54   ` Joseph Myers
2018-07-27 15:11     ` Michael Matz
2018-07-28  0:26       ` Paul Smith
2018-07-30 14:34         ` Joseph Myers
2018-07-28 12:11     ` Ramana Radhakrishnan
2018-07-28 17:23       ` David Malcolm
2018-07-30 14:51       ` Joseph Myers
2018-07-30 16:29         ` Andreas Schwab
2018-07-28  2:29 ` konsolebox
     [not found] <1531832440.64499.ezmlm@gcc.gnu.org>
2018-07-17 17:13 ` Basile Starynkevitch
2018-07-17 23:52   ` David Malcolm
2018-07-17 20:37 David Niklas
2018-07-18  0:23 ` David Malcolm
2018-07-18  0:38   ` Paul Koning
2018-07-18 16:41   ` doark
2018-07-18 17:22     ` doark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc1ti+nX4pGoJQkPXVeVijNsZgwYviEJaeNTC4FJ4hxpHg@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).