public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [RFC] database with API information
@ 2022-09-07  6:22 Ulrich Drepper
  2022-09-07 10:56 ` Richard Sandiford
  2022-09-09 11:40 ` SAIFI
  0 siblings, 2 replies; 14+ messages in thread
From: Ulrich Drepper @ 2022-09-07  6:22 UTC (permalink / raw)
  To: Ulrich Drepper via Gcc

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

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.


Opinions?

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-09-09 20:05 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-07  6:22 [RFC] database with API information Ulrich Drepper
2022-09-07 10:56 ` Richard Sandiford
2022-09-07 12:33   ` Martin Liška
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

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).