From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 3EEA7385841A for ; Wed, 7 Sep 2022 10:56:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3EEA7385841A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 18CDA1042; Wed, 7 Sep 2022 03:56:54 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 538063F7B4; Wed, 7 Sep 2022 03:56:47 -0700 (PDT) From: Richard Sandiford To: Ulrich Drepper via Gcc Mail-Followup-To: Ulrich Drepper via Gcc ,Ulrich Drepper , richard.sandiford@arm.com Cc: Ulrich Drepper Subject: Re: [RFC] database with API information References: Date: Wed, 07 Sep 2022 11:56:46 +0100 In-Reply-To: (Ulrich Drepper via Gcc's message of "Wed, 7 Sep 2022 08:22:41 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-43.1 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Ulrich Drepper via Gcc 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. Thanks, Richard