From: Iain Sandoe <idsandoe@googlemail.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: GCC Development <gcc@gcc.gnu.org>
Subject: Re: [RFC] database with API information
Date: Fri, 9 Sep 2022 16:26:34 +0100 [thread overview]
Message-ID: <6CBFC8BD-97C0-46EA-9D7F-6AD72146B9E8@googlemail.com> (raw)
In-Reply-To: <d46837f7-34fe-9fa3-2ea0-f520fbcbb2e6@suse.cz>
> On 7 Sep 2022, at 13:33, Martin Liška <mliska@suse.cz> wrote:
>
> 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.
( no objection to using Python here )
One small request, I realise that Python 2 is dead, but I regularly bootstrap GCC
on older machines that only have Python 2 installations. If possible (and it sounds
plausible if the job is really quite simple) - it would be good to support those older
machines without having to take a detour to find a way to build Python 3 on them first.
Iain
next prev parent reply other threads:[~2022-09-09 15:26 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
2022-09-09 15:26 ` Iain Sandoe [this message]
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=6CBFC8BD-97C0-46EA-9D7F-6AD72146B9E8@googlemail.com \
--to=idsandoe@googlemail.com \
--cc=drepper@redhat.com \
--cc=gcc@gcc.gnu.org \
/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).