From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35342 invoked by alias); 31 Mar 2017 18:46:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 35321 invoked by uid 89); 31 Mar 2017 18:46:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=mitigate, hopping, Hx-languages-length:2594, states X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Mar 2017 18:46:48 +0000 Received: by simark.ca (Postfix, from userid 33) id 667ED1E9AB; Fri, 31 Mar 2017 14:46:48 -0400 (EDT) To: Pedro Alves Subject: Re: [PATCH v2] gdbserver: Suffix generated C files with -generated X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 31 Mar 2017 18:46:00 -0000 From: Simon Marchi Cc: Simon Marchi , gdb-patches@sourceware.org In-Reply-To: <3038cd35b397eeafa1f8f0447630fa8e@polymtl.ca> References: <20170331145554.26349-1-simon.marchi@ericsson.com> <38db6e08-ed78-59ce-a514-03398fe5fe70@redhat.com> <3038cd35b397eeafa1f8f0447630fa8e@polymtl.ca> Message-ID: <10b63a1c35681aac4f5683f16549ec60@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.4 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00555.txt.bz2 On 2017-03-31 11:40, Simon Marchi wrote: > On 2017-03-31 11:12, Pedro Alves wrote: >> On 03/31/2017 03:55 PM, Simon Marchi wrote: >>> From: Simon Marchi >>> >>> I noticed that there were some missing files in gdbserver's gitignore >>> (some generated register format .c files). Of course the easy fix >>> would >>> be to add those files to .gitignore, but I think we can do a better >>> job, >>> so that we don't have to worry about adding generated files to >>> .gitignore or the clean Makefile target. >>> >>> I suggest naming all generated source files -generated.c. This way, >>> we >>> can use a single rule in .gitignore and do a "rm -f *-generated.c" to >>> clean them up. >>> >>> New in v2: >>> >>> - Don't rename version.o and xml-builtin.o >>> >>> gdb/gdbserver/ChangeLog: >>> >>> * .gitignore: Remove generated files, replace with wildcard. >>> * (clean): Replace removal of generated files with wildcard. >>> (version.c): Replace with... >>> (version-generated.c): ...this. >>> (xml-builtin.c): Replace with... >>> (xml-builtin-generated.c): ...this. >>> (%-ipa.o: %-generated.c, %.o: %-generated.c): New rules. >>> (%.c: *regformats*): Replace with... >>> (%-generated.c: *regformats*): ...this. >> >> OK. > > Thanks, pushed. Note that when updating past this commit and rebuilding, or in general hopping back and forth between branches that have this commit and branches that don't and rebuilding, you may stumble on errors like: make: *** No rule to make target `version.c', needed by `version.o'. Stop. It's the same issue some people had when environ.c was moved to common/environ.c, and it will happen every time we move a source file. The reason is the leftover dependency file in .deps, containing something like: version.o: version.c These files are automatically generated by gcc and state all the files that went into creating version.o during the last build. That rule states that version.c should exist when for version.o to be built, and that version.o should be rebuilt if version.c is more recent. But version.c was moved and no longer exists, hence the error. One thing I see we could do to mitigate the problem is clear the .deps directory when doing a "make clean". After all, when doing a clean, all objects are deleted and are going to be rebuilt, so we don't care about the dependencies anymore. So if somebody stumbles on that problem, there's a chance they'll try to clean and build again, which would fix the problem. Do you have any better idea? Simon