Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

[Fredrik Öhrström]

2012-12-03 17:55, Kelly O'Hair skrev:
> I notice that some of the $@.tmp stuff has been removed, along with the "$(RM) $@ $@.tmp" commands.
> I know it's a pain to do this, but I have found it necessary, especially on Windows for some reason.

What reason? Can you give an example where it fails on windows?

> The "$(MKDIR) -p $(@D)" guarantees that the destination directory exists, glad those remain.
> The "$(RM) $@" is done to make sure the target file is removed so we get a fresh file. If some command
> in the rules fail, I'd rather not see some partial $@ file left around from some previous build.
> The use of $@.tmp files, followed by a "$(MV) $@.tmp $@" was to avoid any issues with a partially
> constructed $@ file being left around, perhaps when some command in the rules got killed by a ^C or 'kill -9',
> and a second make command thinking the file did not need to be built.

Make knows how to cleanup the goal file, if the recipe is interrupted 
halfway.

Take for example this makefile:

myprog.sh :
         echo "#!/bin/sh" > $@
         sleep 3
         echo "echo Hello World!" >> $@
         echo >> $@
         chmod a+x $@

If you press ctrl-c during the sleep, then make will remove the half 
baked myprog.sh
and print: ^Cmake: *** Deleting file `myprog.sh'
make: *** [myprog.sh] Interrupt

However if you have an error in you recipe, for example add "cat 
not_there >> $@" at the end
of the recipe, then make will let the half baked  myprog.sh remain. But 
makefile execution
will of course terminate.

Thus if you have a recipe that will most likely not fail, then you 
should rely on make to do the
cleanup. If you have potential failures during a sequence of commands 
that construct the goal,
then the tmp trick should be used, to avoid incorrect goals remaining 
and confusing future incremental builds.

ALSO, if the recipe is triggered because the goal timestamp is older 
than the dependency timestamp,
then there is no need to remove the goal. If the goal is not 
regenerated, then a simple touch of the goal is enough.

On the windows file system, the timestamp resolution on FAT32 is 2 
seconds and can cause odd rounding
that (un)triggers goal dependency timestamp comparisons. This problems 
is solved by avoiding FAT32.

//Fredrik