Re: [PATCH] C++ API database

[Jason Merrill <jason@redhat.com>]

On 9/28/22 12:59, Ulrich Drepper via Gcc-patches wrote:
> Ping.  Anyone having problems with this?  And the governance of the file?

Hmm, for some reason this didn't show up on my C++ patches filter. 
Please do CC me when pinging C++ patches.

> On Mon, Sep 12, 2022 at 1:51 PM Ulrich Drepper <drepper@redhat.com> wrote:
> 
>> After my prior inquiry into the use of python as a build tool for
>> maintainers didn't produce any negative comments and several active and
>> even enthusiastic support message I'm going forward with submitting the
>> patch.
>>
>> To repeat the detail, for the generation of the upcoming C++ standard
>> library module and the hints for missing definitions/declarations in the
>> std:: namespace we need a list of standard C++ APIs.  The information
>> needed for the two use cases is different but the actual APIs overlap
>> almost completely and therefore it would be a bad idea to have the data
>> separated.
>>
>> We could opt for a file format that is easy to read in awk and writing the
>> appropriate scripts to transform the data into the appropriate output
>> format but this looks ugly, is hard to understand, and a nightmare to
>> maintain.  On the other hand, writing the code in Python is simple and
>> clean.
>>
>>
>> Therefore, Jonathan and I worked on a CSV file which contains the
>> necessary information and a Python to create the gperf input file to
>> generate std-name-hint.h and also, in future, the complete source of the
>> export interface description for the standard library module.  This mode is
>> not yet used because the module support isn't ready yet.  The output file
>> corresponds to the hand-coded version of the export code Jonathan uses
>> right now.
>>
>> Note that in both of these cases the generated files are static, they
>> don't depend on the local configuration and therefore are checked into the
>> source code repository.  The script only has to run if the generated files
>> are explicitly removed or, in maintainer mode, if the CSV file has
>> changed.  For normal compilation from a healthy source code tree the tool
>> is not needed.
>>
>>
>> One remaining issue is the responsibility for the CSV file.  The file
>> needs to live in the directory of the frontend and therefore nominally
>> changes need to be approved by the frontend maintainers.  The content
>> entirely consists of information from the standard library, though.  Any
>> change that doesn't break the build on one machine (i.e., the Python script
>> doesn't fail) will not course any problem because the output format of the
>> script is correct.  Therefore we have been wondering whether the CSV file
>> should at least have shared ownership between the frontend maintainers and
>> the libstdc++ maintainers.

That makes sense; the file could say something to that effect.  Or the 
CSV file could live in the library directory, or a third directory.  And 
maybe separate the two generators; it seems like the code shared between 
them is pretty small.

>> The CSV file contain more hint information than the old hand-coded .gperf
>> file.  So, an additional effect of this patch is the extension of the hints
>> that are provided but given that the lookup is now fast this shouldn't have
>> any negative impact.  The file is not complete, though, this will come over
>> time and definitely before the module support is done.
>>
>> I build my complete set of compilers with this patch without problems.
>>
>> Any comments?

Generally, looks good.

The CSV file could use a header row documenting the fields (as well as 
the documentation in the script).

> +# This is the file that depends in the generated header file.

s/in/on/

Jason