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
