From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id C3FF33858401 for ; Tue, 18 Oct 2022 11:05:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C3FF33858401 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id BE23620554; Tue, 18 Oct 2022 11:04:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1666091099; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XZqPLzwm458xz8uiri8atdsFYTat0Wh1Gts7hKsE1gQ=; b=EoPGfiWoa0w6tv7fUAxwWdtSL2c44ApMoyojgYT2nl1nC17Kqa/IJXATSe0kBaE2DT00rE tKXG42+wJupHLdxBRHtMT4cWnr7dSzMnlRcreDJVDNPI9yrticXcxYd3yE35vwO2esZ3MK QxjLiB4qc9CHUfHzT9TjHIrqdf400t0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1666091099; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XZqPLzwm458xz8uiri8atdsFYTat0Wh1Gts7hKsE1gQ=; b=Ci+c0uzI2lxSddp2TS3ALfCv+La+Ce3WzfnuK0r/wG0I431BN4tWhzOotwJb+JKIHL8diD bKRZzAT76U4jttCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A3374139D2; Tue, 18 Oct 2022 11:04:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id QyqBHVuITmO/QgAAMHmgww (envelope-from ); Tue, 18 Oct 2022 11:04:59 +0000 Message-ID: <8d8833ad-711c-6b13-c003-bb4134a70d35@suse.cz> Date: Tue, 18 Oct 2022 13:04:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH] C++ API database Content-Language: en-US To: Ulrich Drepper , Jason Merrill Cc: gcc-patches@gcc.gnu.org References: <2afc8d88-2c00-a134-7d5d-da6b7c388563@redhat.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/18/22 13:01, Ulrich Drepper via Gcc-patches wrote: > On Tue, Oct 18, 2022 at 2:56 AM Jason Merrill wrote: > >> That makes sense; the file could say something to that effect. > > > I did that. > > > >> Or the >> CSV file could live in the library directory, or a third directory. > > > The reasoning is that with the file living in the cp subdir we don't have > the situation that the compiler sources depend on something that lives > elsewhere. Unless I miss something, there are no such outside dependencies > and one can build the compiler without the libstdc++ subdir to exist. > > > > >> And >> maybe separate the two generators; it seems like the code shared between them >> is pretty small. >> > > The shared code as-is is small, but so is the whole script. > > Unless someone feels strongly about it I'd prefer not to split the file. > It is far easier to forget to make adequate changes in multiple places. > There can be changes to the format going forward and even yet another > consumer of that information. Keeping more than one (or two, if you count > the CSV file) places is sync is asking for trouble. > > > The CSV file could use a header row documenting the fields (as well as > >> the documentation in the script). >> > > I duplicated the information from the script in the CSV file itself. > > > >>> +# This is the file that depends in the generated header file. >> >> s/in/on/ >> > > Done. > > > There is one additional issue, though, which will likely not hit anyone > here but theoretically is handled in the current version of the build > infrastructure. > > The Makefile contains the provision outside of maintainer mode to rebuild > the generated files by removing the generated file first. This will > require the tools (gperf) to be available but that's deemed OK. > > With this CSV file as the source of the information we have a two-step > derivation of the generated file, though: > > CSV -> .gperf -> .h > > The trick used to avoid the rebuild of the .h file today is to not have a > prerequisite for the rule. This doesn't work for the two-step process. If > the .h and.gperf files are removed there would be no information about the > dependency of the .h generation on the .gperf file. > > This is of course not a new problem in general. GNU make has for a long > time support for order-only prerequisites. With those one can exactly > express what is needed: > > ifeq ($(ENABLE_MAINTAINER_RULES), true) > FOO.h: FOO.gperf > else > FOO.h: | FOO.gperf > endif > gperf ... > > ifeq ($(ENABLE_MAINTAINER_RULES), true) > FOO.gperf: CSV > else > FOO.gperf: | CSV > endif > python ... > > The question here is whether there is a reason not to depend on GNU make > features (and whatever other make implemented this extension). > > > The alternative would be to not expose the .gperf file at all, remove it > from git and remove it after the .h file was created. This gets us back to > a one-step process which the unclean make trick can handle. > > I haven't found an obvious place where tool dependencies are recorded so I > have no idea what the assumptions are. > > Any comment on this? > > I have a patch with the order-only rule ready to send out. Hi. Can you please fix the coding style of the newly added Python scripts? I documented what's expected from Python scripts here: https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commitdiff;h=ece15e0758bdbb6938942a9f91f6342e66fe443a But unfortunately, the change hasn't reached yet: https://gcc.gnu.org/codingconventions.html The issues I see: gcc/cp/gen-cxxapi-file.py:34:80: E501 line too long (96 > 79 characters) gcc/cp/gen-cxxapi-file.py:35:80: E501 line too long (103 > 79 characters) gcc/cp/gen-cxxapi-file.py:61:1: W293 blank line contains whitespace gcc/cp/gen-cxxapi-file.py:63:1: W293 blank line contains whitespace gcc/cp/gen-cxxapi-file.py:71:11: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:72:19: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:77:27: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:84:31: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:90:1: E302 expected 2 blank lines, found 1 gcc/cp/gen-cxxapi-file.py:132:11: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:133:19: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:137:27: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:141:31: E225 missing whitespace around operator gcc/cp/gen-cxxapi-file.py:144:1: E302 expected 2 blank lines, found 1 gcc/cp/gen-cxxapi-file.py:150:1: E305 expected 2 blank lines after class or function definition, found 1 gcc/cp/gen-cxxapi-file.py:155:1: E302 expected 2 blank lines, found 1 gcc/cp/gen-cxxapi-file.py:159:1: E302 expected 2 blank lines, found 1 gcc/cp/gen-cxxapi-file.py:167:8: E713 test for membership should be 'not in' gcc/cp/gen-cxxapi-file.py:173:80: E501 line too long (91 > 79 characters) gcc/cp/gen-cxxapi-file.py:178:80: E501 line too long (81 > 79 characters) gcc/cp/gen-cxxapi-file.py:181:1: E305 expected 2 blank lines after class or function definition, found 1 Note that we may want to relax the E501 issues to something like 120 chars: see: ./maintainer-scripts/setup.cfg Thanks, Martin