public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Martin Liška" <mliska@suse.cz>
To: Ulrich Drepper via Gcc <gcc@gcc.gnu.org>,
	Ulrich Drepper <drepper@redhat.com>,
	richard.sandiford@arm.com
Subject: Re: [RFC] database with API information
Date: Wed, 7 Sep 2022 14:33:59 +0200	[thread overview]
Message-ID: <d46837f7-34fe-9fa3-2ea0-f520fbcbb2e6@suse.cz> (raw)
In-Reply-To: <mptczc7a1w1.fsf@arm.com>

On 9/7/22 12:56, Richard Sandiford via Gcc wrote:
> Ulrich Drepper via Gcc <gcc@gcc.gnu.org> writes:
>> I talked to Jonathan the other day about adding all the C++ library APIs to
>> the name hint file now that the size of the table is not really a concern
>> anymore.
>>
>> Jonathan mentioned that he has to create and maintain a similar file for
>> the module support.  It needs to list all the exported interfaces and this
>> is mostly a superset of the entries in the hint table.
>>
>> Instead of duplicating the information it should be kept in one place.
>> Neither file itself is a natural fit because the additional information
>> needed  (e.g., the standard version information for the name hint table) is
>> not needed in the other location.
>>
>> Hence, let's use a simple database, a CSV file for simplicity, and generate
>> both files from this.  Easily done, I have an appropriate script and a CSV
>> file with the information of both Jonathan's current export file and the
>> current state of the name hint table.
>>
>> The only detail that keeps me from submitting this right now is the way the
>> script is implemented.  This is just a natural fit for a Python script.
>> The default installation comes with a csv module and there are nice ways to
>> adjust and output boilerplate headers like those needed in those files.
>>
>> It would be possible to create separate awk scripts (there is only one
>> Python script) but it'll be rather ugly and harder to maintain than the
>> Python version.
>>
>> Of course the problem is: I don't think that there is yet any maintainer
>> tool written in Python (except some release engineering tools).  The
>> question is therefore: is it time to lift this restriction?  I cannot today
>> imagine any machine capable of serving a gcc developer which doesn't also
>> have a Python implementation.  As long as there is no dependency on exotic
>> modules I doubt that anything will break.
> 
> FWIW, I agree it's past time to lift the no-Python restriction,
> and that Python is a natural fit for stuff like this.

+1 for me!

Martin

> 
> Thanks,
> Richard


  reply	other threads:[~2022-09-07 12:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-07  6:22 Ulrich Drepper
2022-09-07 10:56 ` Richard Sandiford
2022-09-07 12:33   ` Martin Liška [this message]
2022-09-09 15:26     ` Iain Sandoe
2022-09-09 17:07       ` Ulrich Drepper
2022-09-09 17:13         ` Iain Sandoe
2022-09-09 11:40 ` SAIFI
2022-09-09 11:47   ` Jonathan Wakely
2022-09-09 12:29     ` SAIFI
2022-09-09 15:06       ` Jonathan Wakely
2022-09-09 16:41         ` SAIFI
2022-09-09 18:21           ` Jonathan Wakely
2022-09-09 18:40             ` SAIFI
2022-09-09 20:05               ` Jonathan Wakely

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=d46837f7-34fe-9fa3-2ea0-f520fbcbb2e6@suse.cz \
    --to=mliska@suse.cz \
    --cc=drepper@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    /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).