From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 743593858C39 for ; Fri, 7 Jan 2022 19:01:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 743593858C39 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-220-8KKsMO55P4i9Bdf5N-nMYw-1; Fri, 07 Jan 2022 14:01:31 -0500 X-MC-Unique: 8KKsMO55P4i9Bdf5N-nMYw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 98F26100F96D; Fri, 7 Jan 2022 19:01:20 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.2.16.169]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DC8CD7D3DB; Fri, 7 Jan 2022 19:01:19 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 207J1HMi1071438 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 7 Jan 2022 20:01:17 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 207J1GST1071437; Fri, 7 Jan 2022 20:01:16 +0100 Date: Fri, 7 Jan 2022 20:01:16 +0100 From: Jakub Jelinek To: Alexandre Oliva Cc: Martin Jambor , GCC Mailing List Subject: Re: Mass rename of C++ .c files to .cc suffix? Message-ID: <20220107190116.GN2646553@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2022 19:01:34 -0000 On Fri, Jan 07, 2022 at 03:33:54PM -0300, Alexandre Oliva via Gcc wrote: > On Jan 7, 2022, Martin Jambor wrote: > > > Would anyone be terribly against mass renaming all *.c files (that are > > actually C++ files) within the gcc subdirectory to ones with .cc suffix? > > I wouldn't mind that. > > > (Any important caveats I might have missed?) > > Having recently renamed a .c source to .cc in a development branch, one > annoying issue that came up was that dependency tracking in build trees > couldn't recover from the renaming on its own: it kept on insisting that > the previously-existing .c file was missing, instead of picking up the > .cc. This could be a problem for hands-off CI testers, besides the > slight annoyance of having to wipe out the build tree, or at least hunt > down and remove dep-tracking files. > > It's no biggie, I'm not sure there's some change to the build machinery > we could make ahead of time to alleviate this, but it should probably be > mentioned in the announcement of the change if/when it goes in. So it will be something to work around in bisection scripts (though sure, over the years we have various quirks in there), e.g. in the svn era I have if [ $rev -gt 202892 ]; then [ ! -f .deps/toplev.Po ] && rm -f `ls -1 *.o */*.o | grep -v 'crt.*o'`; else [ -d .deps ] && rm -rf .deps */.deps; fi Jakub