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
