Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That leaves behind a tmp file breadcrumb if generate fails, or the recipe is interrupted by a signal. You can address some of that that by cramming more logic into the recipe.

I was going to fix it in exactly that way, but I could just could not believe that such a workaround would is required. Why can't Make take care of such an obvious thing?

So I went digging into the manual, which I had read before more than one time, to see if I overlooked something.

Setting DELETE_ON_ERROR is superior.



> Setting DELETE_ON_ERROR is superior.

Relying on .DELETE_ON_ERROR will fail to delete the file if your Make process is killed abruptly, in such a way that Make can't clean up. Things like killed by OOM killer, power failure (laptop battery), network filesystem suddenly dropped, VM killed with make in progress, kernel froze (it's happened to me).

That said, many of those things result in an inconsistent state using the "mv" or "move-if-changed" method too, because who calls fsync from a shell script in the right places. It's better to detect that Make didn't get the chance to clean up, so you know "make clean" or equivalent is necessary next time.

("make clean" can be a right pain for build processes that take hours or days to rebuild though. In one project I worked on, it took 20 minutes just for GNU Make to do the stat() calls to get the timestamps to decide what to build, before it ran the first command. Imagine how long the actual rebuild from scratch took.)


The recipes that I'm concerned about will show this issue 100% of the time if the generating command touches the output file and then fails.

GNU Make offers us a blanket solution for such cases and so we should take advantage of it.

That solution doesn't nail all the the corner cases like being killed by uncatchable signals or kernels crashing.

That issue affects not only the recipes I'm presently concerned about but potentially all recipes. Even those which ensure that the file is gone when the tool fails.

Fixing that problem likely requires changing every single recipe in every Makefile, except for those which invoke a tool that already does an atomic create or update, or reasonably simulated facsimile thereof.


> That leaves behind a tmp file breadcrumb if generate fails

That sounds useful for debugging the failure. But better then to do:

    foo: bar
        generate bar > foo.tmp && mv foo.tmp foo
So you can at least tell what it was supposed to be.


That leaves behind a tmp file breadcrumb if generate fails, or the recipe is interrupted by a signal.

Honest question: Why does that matter?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: