Patch create bison files atomically

Alexandre Oliva
Fri Oct 13 10:24:00 GMT 2000

On Oct 13, 2000, "Kaveh R. Ghazi" <> wrote:

>> From: Alexandre Oliva <>
>> On Oct 12, 2000, "Kaveh R. Ghazi" <> wrote:
>> >> I think I've just figured out why you chose to use move-if-change.
>> > Feel free to fill me in.  I don't think I had a good reason. :-)
>> If you have already generated the file in this session (i.e., it's
>> already up-to-date), you'd better not change its timestamp again,
>> otherwise builds that have already used the previous timestamp may
>> suddenly need to compile the generated files again.

> Sure, that's the whole rationale behind move-if-change.  But as you
> pointed out in your previous message, we do want to update the
> timestamp or else the bison file will get regenerated over and over.

I haven't explained well what I had mind.  In case of concurrent
builds, if one completes the generation very quickly, whereas the
other takes a long time to do so, we wouldn't want the slower one to
update the timestamp of the generated file while the faster one has
already compiled the version it built, because then the object file
would have a timestamp older than the file generated by the slower

Of course, my proposal would be any safer in case both machines
generate exactly the same file.  In case they don't, inconsistencies
are to be expected, anyway.

> 2000-10-12  Kaveh R. Ghazi  <>

> 	* (c-parse.c, tradcif.c): Create atomically.
> 	* objc/ (objc-parse.c): Likewise.
> cp:
> 	* (parse.c, parse.h): Create atomically.

> java:
> 	* (parse.c, parse-scan.c): Create atomically.
> 	* (parse.c, parse-scan.c): Likewise.

This looks ok to me.  Please install it.

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

More information about the Gcc-patches mailing list