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 <drep...@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

Reply via email to