[RFC] database with API information

[Martin Liška]

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