Re: [PATCH v3] Added file properties to windows gdb executable for all mingw32 builds.

[Pedro Alves <palves@redhat.com>]

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  <bernd.bunk@intel.com>
>>>
>>> 	* 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