From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1542 invoked by alias); 26 Aug 2013 14:49:38 -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 1533 invoked by uid 89); 26 Aug 2013 14:49:37 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Aug 2013 14:49:37 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7QEnWb9027837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Aug 2013 10:49:33 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r7QEnVTj022384; Mon, 26 Aug 2013 10:49:31 -0400 Message-ID: <521B6AFA.1010101@redhat.com> Date: Mon, 26 Aug 2013 14:49:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Bunk, Bernd" CC: "tromey@redhat.com" , "eliz@gnu.org" , "gdb-patches@sourceware.org" Subject: Re: [PATCH v3] Added file properties to windows gdb executable for all mingw32 builds. References: <1377273278-10370-1-git-send-email-bernd.bunk@intel.com> <52178748.9070909@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00742.txt.bz2 On 08/26/2013 01:30 PM, Bunk, Bernd wrote: >> -----Original Message----- >> From: Pedro Alves [mailto:palves@redhat.com] >> Sent: Friday, August 23, 2013 6:01 PM >> To: Bunk, Bernd >> Cc: tromey@redhat.com; palves@redhat.com; eliz@gnu.org; gdb- >> patches@sourceware.org >> Subject: Re: [PATCH v3] Added file properties to windows gdb executable >> for all mingw32 builds. >> >> On 08/23/2013 04:54 PM, Bernd Bunk wrote: >>> On Windows OS it is custom that executables and DLL's show file >> properties. >>> These contain product name/version, file name/version, >> company/copyright info. >>> File properties are visible by right-click on the file, selecting >> properties \ details. >>> This patch adds file properties to the gdb executable for all mingw >> builds. >>> >>> 2013-08-14 Bernd Bunk >>> >>> * Makefile.in (windows_exe_properties.h): Add rule to create >>> windows_exe_properties.h header file with file property >> information. >>> (windows_exe_properties.o): Added rule to build the resource >> file. >> >> I didn't find where this was updated to write to a temporary file, and >> then move to the final destination. Did I miss something? > Sorry forgot to answer to this. As mentioned in a PATCH v2 answer, I don't need to copy it. I just removed the $(srcdir) folder infront of the filename in the shell script and added a "-I." to the build rule. So the RC file now includes the header file from the local folder, which is the build folder. But if you don't like this solution I can change it... Indeed, generating in the build dir is something that should be done too, so good that you fixed that. But I actually wasn't talking about that issue. I'm talking about the standard solution for the problem of the build being interrupted after the generated file has started being written to, but before it's completely generated. In the scenario, you end up with an incomplete generated file in the build dir. The next time you run "make", make, which only looks at timestamps, will see the file already exists, and will thus skip regenerating it. As the generated file is incomplete, naturally the build will fail, or worse, will succeed, but end up with a program that fails at runtime in mysterious ways. So, instead, the solution is for the make rule for generated files to generate the file in a temporary location, and then do a final atomic move to the final destination. The temporary location should indeed be in the build dir. It isn't for the copying.c rule, because that is a generated file that we check in to the repository, as opposed to a generated file that only exists in the build dir. See e.g., the init.c rule for an example that generates init.c-tmp in the build dir, and the moves/renames it to the final init.c. Or even, the create-version.h script you copied from, which also uses the same technique. -- Pedro Alves