bug#11377: configure.am - fails to remove configure before attempting replacement

[Ronald F. Guilmette]

In message <address@hidden>, 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.)