[RFC] database with API information

[Ulrich Drepper <drepper@redhat.com>]

[-- 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?