Re: Makefile bug in generating mh-loaddefs.el?

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@ics.uci.edu>
>> Date: Tue, 03 Jul 2007 11:42:29 -0700
>> 
>> $(lisp)/mh-e/mh-loaddefs.el: $(MH_E_SRC)
>> 	echo ";;; mh-loaddefs.el --- automatically extracted autoloads" > $@

[...]

>> Now, if the "$(EMACS) $(EMACSOPT) -l autoload ..." fails, the
>> mh-loaddefs.el file will not be deleted. That seems like a bug to
>> me...
>
> Could you please explain what do you mean by ``will not be
> deleted'', and why you think it's a bug?  The `echo' commands
> overwrite mh-loaddefs.el, don't they? which is akin to deleting the
> (old) file, right?

Not to make.  An empty file is not remade by "make" on a subsequent
run, as opposed to a non-existing file.

> Anyway, of Emacs fails, then Make will stop and announce the error;
> therefore I don't see why you (evidently) want an additional
> manifestation of the problem.
>
> What am I missing?

The behavior in additional runs of make.

(info "(make) Errors")

[...]

   Usually when a command fails, if it has changed the target file at
all, the file is corrupted and cannot be used--or at least it is not
completely updated.  Yet the file's time stamp says that it is now up to
date, so the next time `make' runs, it will not try to update that
file.  The situation is just the same as when the command is killed by a
signal; *note Interrupts::.  So generally the right thing to do is to
delete the target file if the command fails after beginning to change
the file.  `make' will do this if `.DELETE_ON_ERROR' appears as a
target.  This is almost always what you want `make' to do, but it is
not historical practice; so for compatibility, you must explicitly
request it.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum