What kind of retard decided that this is a sensible behavior
I'm using Make to implement a workflow, and here I use a bunch of files to indicate that certain tasks have completed. They are not the results of the tasks, I just touch files to indicate that the given task is completed since that is the simplest way to tag that.
There is a bit of chaining going on, so a makefile like this is pretty representative:
all: foo.c .PHONY: all %.a: touch $@ %.b: %.a touch $@ %.c: %.b touch $@
Now, if I run this, this happens:
$ make touch foo.a touch foo.b touch foo.c rm foo.b foo.a
Why does it delete foo.a and foo.b? I didn't ask it to, and I certainly don't want it to. Tasks a and b are completed, and I don't want to redo them later unless I explicitly ask for it, so why does Make delete the fact that the tasks are done?
It doesn't delete the last file, foo.c, so it is not completely useless, just 99% useless...
--
268-300=-32
September 25th, 2009 at 2:42 pm
Turns out I can turn this off using the .PRECIOUS target ... but I still hate that this is the default behaviour
September 25th, 2009 at 3:41 pm
I actually find it very sensible behavior. In the first line of your makefile, you write "all: foo.c", which means that the only file you want made is foo.c; if you wanted foo.a and foo.b as well, the line should read "all: foo.a foo.b foo.c". As I see it, the only alternative to this behavior would be that make never cleaned up after itself and left all intermediary files behind despite you never having asked for them.
September 26th, 2009 at 8:16 am
As I see it, if I care enough about a file to create it in the make file, I care enough to keep it. Unless I explicitly say otherwise.
Do you expect to loose all .o files after you compile a program? The .o files are temporary, and you are only interested in the final binary, but if you delete them after the final linking, you have to remake all .o files if you change a single .c file, which is certainly not the kind of behaviour I expect from Make!