Makefile bug in generating mh-loaddefs.el?

Makefile bug in generating mh-loaddefs.el?

[Dan Nicolaescu]

mh-loaddefs.el is generated like this: 

$(lisp)/mh-e/mh-loaddefs.el: $(MH_E_SRC)
	echo ";;; mh-loaddefs.el --- automatically extracted autoloads" > $@
	echo "" >> $@
	echo ";; Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc." >> $@
	echo ";; Author: Bill Wohler <wohler@newt.com>" >> $@
	echo ";; Keywords: mail" >> $@
	echo ";;; Commentary:" >> $@
	echo ";;; Change Log:" >> $@
	echo ";;; Code:" >> $@
	echo "\f" >> $@
	echo "(provide 'mh-loaddefs)" >> $@
	echo ";; Local Variables:" >> $@
	echo ";; version-control: never" >> $@
	echo ";; no-byte-compile: t" >> $@
	echo ";; no-update-autoloads: t" >> $@
	echo ";; End:" >> $@
	echo ";;; mh-loaddefs.el ends here" >> $@
	$(EMACS) $(EMACSOPT) \
	   -l autoload \
	   --eval "(setq generate-autoload-cookie \";;;###mh-autoload\")" \
	   --eval "(setq generated-autoload-file \"$(lisp)/mh-e/mh-loaddefs.el\")" \
	   --eval "(setq make-backup-files nil)" \
	   -f batch-update-autoloads $(lisp)/mh-e


Now, if the "$(EMACS) $(EMACSOPT) -l autoload ..." fails, the
mh-loaddefs.el file will not be deleted. That seems like a bug to me...

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

[Eli Zaretskii]

> 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" > $@
> 	echo "" >> $@
> 	echo ";; Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc." >> $@
> 	echo ";; Author: Bill Wohler <wohler@newt.com>" >> $@
> 	echo ";; Keywords: mail" >> $@
> 	echo ";;; Commentary:" >> $@
> 	echo ";;; Change Log:" >> $@
> 	echo ";;; Code:" >> $@
> 	echo "\f" >> $@
> 	echo "(provide 'mh-loaddefs)" >> $@
> 	echo ";; Local Variables:" >> $@
> 	echo ";; version-control: never" >> $@
> 	echo ";; no-byte-compile: t" >> $@
> 	echo ";; no-update-autoloads: t" >> $@
> 	echo ";; End:" >> $@
> 	echo ";;; mh-loaddefs.el ends here" >> $@
> 	$(EMACS) $(EMACSOPT) \
> 	   -l autoload \
> 	   --eval "(setq generate-autoload-cookie \";;;###mh-autoload\")" \
> 	   --eval "(setq generated-autoload-file \"$(lisp)/mh-e/mh-loaddefs.el\")" \
> 	   --eval "(setq make-backup-files nil)" \
> 	   -f batch-update-autoloads $(lisp)/mh-e
> 
> 
> 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?

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?

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

[David Kastrup]

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

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

[Tom Tromey]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

[from the make manual]
>> `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.

Another typical, and portable, approach is to create a temporary file
and then 'mv' it to the correct name at the end of the rule.

Tom

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

[Dan Nicolaescu]

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" > $@
  > > 	echo "" >> $@
  > > 	echo ";; Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc." >> $@
  > > 	echo ";; Author: Bill Wohler <wohler@newt.com>" >> $@
  > > 	echo ";; Keywords: mail" >> $@
  > > 	echo ";;; Commentary:" >> $@
  > > 	echo ";;; Change Log:" >> $@
  > > 	echo ";;; Code:" >> $@
  > > 	echo "\f" >> $@
  > > 	echo "(provide 'mh-loaddefs)" >> $@
  > > 	echo ";; Local Variables:" >> $@
  > > 	echo ";; version-control: never" >> $@
  > > 	echo ";; no-byte-compile: t" >> $@
  > > 	echo ";; no-update-autoloads: t" >> $@
  > > 	echo ";; End:" >> $@
  > > 	echo ";;; mh-loaddefs.el ends here" >> $@
  > > 	$(EMACS) $(EMACSOPT) \
  > > 	   -l autoload \
  > > 	   --eval "(setq generate-autoload-cookie \";;;###mh-autoload\")" \
  > > 	   --eval "(setq generated-autoload-file \"$(lisp)/mh-e/mh-loaddefs.el\")" \
  > > 	   --eval "(setq make-backup-files nil)" \
  > > 	   -f batch-update-autoloads $(lisp)/mh-e
  > > 
  > > 
  > > 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?
  > 
  > 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?

Do this

rm src/emacs mh-e/mh-loaddefs.el
cd lisp
make mh-autoloads

"make mh-autoloads" will fail, now run "make mh-autoloads" again and it will
succeed...

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

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Tue, 03 Jul 2007 13:55:24 -0700
> Cc: emacs-devel@gnu.org
> 
> Do this
> 
> rm src/emacs mh-e/mh-loaddefs.el
> cd lisp
> make mh-autoloads
> 
> "make mh-autoloads" will fail, now run "make mh-autoloads" again and it will
> succeed...

I think this is true for almost any other target in lisp/Makefile.

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

[Bill Wohler]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@ics.uci.edu>
>> Date: Tue, 03 Jul 2007 13:55:24 -0700
>> Cc: emacs-devel@gnu.org
>> 
>> Do this
>> 
>> rm src/emacs mh-e/mh-loaddefs.el
>> cd lisp
>> make mh-autoloads
>> 
>> "make mh-autoloads" will fail, now run "make mh-autoloads" again and it will
>> succeed...
>
> I think this is true for almost any other target in lisp/Makefile.

I agree with Eli. The mh-loaddefs.el rule is essentially a copy of the
loaddefs.el rule. If the mh-loaddefs.el rule needs to be fixed, all of
the rules need to be fixed.

> 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.

I'm not sure I'd agree with this practice. If the command fails, the
remnants of the target file could be used for troubleshooting.

Tom's approach--writing to a temporary file and moving it at the
end--seems to answer all issues.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

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

[David Kastrup]

Bill Wohler <wohler@newt.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> 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.
>
> I'm not sure I'd agree with this practice. If the command fails, the
> remnants of the target file could be used for troubleshooting.

In most cases, executing the command via copy&paste is possible.

> Tom's approach--writing to a temporary file and moving it at the
> end--seems to answer all issues.

For people who like temporary files lying around.

-- 
David Kastrup

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

[Stephen J. Turnbull]

David Kastrup writes:

 > In most cases, executing the command via copy&paste is possible.
 > 
 > > Tom's approach--writing to a temporary file and moving it at the
 > > end--seems to answer all issues.
 > 
 > For people who like temporary files lying around.

There won't be any file "lying around" unless it's needed for
debugging.  "make clean" should probably take care of this, and "make
distclean" certainly should.

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

[Tom Tromey]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

>> Tom's approach--writing to a temporary file and moving it at the
>> end--seems to answer all issues.

David> For people who like temporary files lying around.

The temporary file will be overwritten the next time you run 'make'.

I was a little surprised to see this objection.  This technique has
been in use for a number of years in automake, among other places.  I
don't recall ever seeing a complaint about it.

Tom

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

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

>>>>> "David" == David Kastrup <dak@gnu.org> writes:
>>> Tom's approach--writing to a temporary file and moving it at the
>>> end--seems to answer all issues.

David> For people who like temporary files lying around.

Tom> The temporary file will be overwritten the next time you run 'make'.

Oops, I realized this isn't clear enough.
The rule ends with 'mv'.  So a temporary file only exists in the case
that the build failed.  In this case it is sometimes useful to see the
contents of the file.  If the rule uses a fixed temporary file name,
then the temp file will not exist after a successful build due to the mv.

Tom

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

[Eli Zaretskii]

> From: Bill Wohler <wohler@newt.com>
> Date: Tue, 03 Jul 2007 21:44:56 -0700
> 
> Tom's approach--writing to a temporary file and moving it at the
> end--seems to answer all issues.

But its implementation would be complicated on Windows, because we'd
be reluctant to request the user to have yet another non-standard
program (mv.exe) to be installed.

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

[David Robinow]

On 7/4/07, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Bill Wohler <wohler@newt.com>
> > Date: Tue, 03 Jul 2007 21:44:56 -0700
> >
> > Tom's approach--writing to a temporary file and moving it at the
> > end--seems to answer all issues.
> But its implementation would be complicated on Windows, because we'd
> be reluctant to request the user to have yet another non-standard
> program (mv.exe) to be installed.
 I'm surprised by this comment.
 1) Windows uses a completely different makefile. One could choose not
to implement the feature on Windows.

 2) cp.exe and rm.exe are already required. Wouldn't the user already
have mv.exe from the same location as cp.exe and rm.exe?

3) What's wrong with "MV = move" in nmake.defs?
 For that matter, why not use copy and del instead of cp and rm ?

Am I missing something?

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

[Eli Zaretskii]

> Date: Wed, 4 Jul 2007 19:06:38 -0400
> From: "David Robinow" <drobinow@gmail.com>
> 
>  1) Windows uses a completely different makefile. One could choose not
> to implement the feature on Windows.

Sure, but then what's the point?  Until now, we tried to do in
makefile.w32-in everything like in Makefile.in.  If what Dan noticed
is a serious problem, shouldn't it be solved on all supported
platforms?

>  2) cp.exe and rm.exe are already required. Wouldn't the user already
> have mv.exe from the same location as cp.exe and rm.exe?

That's what I said: it's another program we need to ask for, and
another test to perform in nt/configure.bat.

> 3) What's wrong with "MV = move" in nmake.defs?

Different versions of Windows have different and subtly incompatible
versions of MOVE.  It might be tricky to write the Makefile's in a way
that works on all those versions.

>  For that matter, why not use copy and del instead of cp and rm ?

The same reason as with MOVE: the behavior is subtly different on
different versions of Windows.  For example, did you know that older
versions of COPY would not copy empty files? did you know that some
versions of DEL accept only one argument, while others accept multiple
arguments?

In sum, I didn't say it's impossible or rocket science, I just said it
would be complicated.