In message <4fa30527.8070...@redhat.com>, you wrote: >Nothing against your style of coding, but I do want to point out that >recommending anyone delete a file before rebuilding its contents is >racy.
I respectfully disagree. >If things crash in the middle, you can be left without the file, Yes. So? You still have the Makefile, which contains all of the instructions for re-making the file in question. >or with a file with incomplete contents. Could you please explain, for my edification, how inserting an initial `rm' would affect this possibility in any way whatsoever? (Some examples might help to illustrate.) I'm not even sure how one would generate a file with "incomplete contents", let alone how that process might or might not be in any way affected by an initial "rm target". >It is always better to >recommend a style of atomic changes - make your target file in a >temporary location (generally in the same directory as the destination), >then use an atomic rename() to overwrite the original file with the >updated file in one go. Again, I cannot envision any circumstance in which what you are suggesting would be of any benefit, in practice. Perhaps you can provide some examples to illustrate your point. In any event, the style of Makefile coding you are suggesting, wherein the final command to remake a given target would be something like: mv tempfile target is not, I would suggest, at all widespread in current practice. In short, even if you could make the case that this is the Best Way To Do Things... a possibility of which I personally am still dubious... in order to get your wish, I do believe that you would have to sally forth and convince the developers of 99.9% of all existing Makefile to rewrite the millions of Makefiles they maintain in order to conform to the new coding standard you are proposing. (Not a very practical idea, in practice.) >I want to reemphasize what I just said - removing a given regular file >before rebuilding it is prone to awful surprises when your build process >is interrupted unexpectedly. I look forward to reviewing examples that would illustrate your point. Regards, rfg P.S. Your suggestion that removing & replacing the contents of a given target file only at the very last second (and only in an atomic operation) is in some sense "best practice" assumes that something would, in fact, go wrong if the given target file were to be removed sooner, before being replaced. I cannot entirely discount the possibility that in some exceptionally rare and obscure cases, target removal prior to replacement might result in some unwanted effects... although I would still like to see some real examples before reaching any final conclusion on that point. However I do believe that in all of the existing correctly coded GNU-style Makefiles where such an issue might arise, the Makefiles in question will already contain a dependency rule for the special .PRECIOUS target. My only point is that in actual practice, use of GNU Make's special .PRECIOUS target is in fact exceedingly rare. I would venture to guess that no more than one tenth of one percent of all GNU-style Makefiles ever written have mentioned .PRECIOUS (and even fewer use this target correctly). And based upon the rarity of cases where the .PRECIOUS target has been found to be either useful or necessary, I think that any assertion of the kind you have made (i.e. that removal of target files in their recipies _before_ they are actually replaced is either always or frequently inadvisable) is, by and large, unfounded. If target removal before replacement always or frequently led to trouble, then virtually all GNU-style Makefiles would contain a rule for the .PRECIOUS target. The fact that so few do, in practice, tends to support the view that target removal separate from and prior to replacement only causes difficulties in exceedingly rare circumstances. (But regardless of how rare or how common such difficulties may be for Makefile targets in general, I think that it is provable that no such difficulties arise in the specific case of the $(top_srcdir)/configure target, specifically, which is the only one that my specific change request pertained to.)