From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bill Wohler Newsgroups: gmane.emacs.devel Subject: Re: Makefile bug in generating mh-loaddefs.el? Date: Tue, 03 Jul 2007 21:44:56 -0700 Organization: Newt Software Message-ID: <87y7hwg4l3.fsf@olgas.newt.com> References: <200707031842.l63IgTR8029247@oogie-boogie.ics.uci.edu> <200707032055.l63KtOIo003839@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1183524375 17820 80.91.229.12 (4 Jul 2007 04:46:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2007 04:46:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 04 06:46:13 2007 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I5wkf-0006c7-Hw for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 06:46:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5wkf-0006GI-2n for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2007 00:46:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I5wjn-0005bJ-Io for emacs-devel@gnu.org; Wed, 04 Jul 2007 00:45:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I5wjm-0005ZS-64 for emacs-devel@gnu.org; Wed, 04 Jul 2007 00:45:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I5wjm-0005Z4-18 for emacs-devel@gnu.org; Wed, 04 Jul 2007 00:45:10 -0400 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I5wjl-0001xz-HL for emacs-devel@gnu.org; Wed, 04 Jul 2007 00:45:09 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I5wjg-0003xZ-A6 for emacs-devel@gnu.org; Wed, 04 Jul 2007 06:45:04 +0200 Original-Received: from h-64-105-35-207.snvacaid.dynamic.covad.net ([64.105.35.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jul 2007 06:45:04 +0200 Original-Received: from wohler by h-64-105-35-207.snvacaid.dynamic.covad.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jul 2007 06:45:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 34 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: h-64-105-35-207.snvacaid.dynamic.covad.net User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux) Cancel-Lock: sha1:trb2JP8OgrRV1OaaH2iv6bHdoTc= X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:74270 Archived-At: Eli Zaretskii writes: >> From: Dan Nicolaescu >> 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 http://www.newt.com/wohler/ GnuPG ID:610BD9AD