From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Sam Steingold Newsgroups: gmane.emacs.devel Subject: Re: emacs floating point error during dump? Date: 13 Jul 2003 19:58:15 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200307081321.h68DLnC3009346@rum.cs.yale.edu> <200307091344.h69DiZXj014067@rum.cs.yale.edu> <200307132306.h6DN6Wpq004158@rum.cs.yale.edu> Reply-To: sds@gnu.org NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1058140724 12080 80.91.224.249 (13 Jul 2003 23:58:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 13 Jul 2003 23:58:44 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jul 14 01:58:42 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19bqjq-00038h-00 for ; Mon, 14 Jul 2003 01:58:42 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19bqwq-0006at-00 for ; Mon, 14 Jul 2003 02:12:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19bqjq-0008QG-Ux for emacs-devel@quimby.gnus.org; Sun, 13 Jul 2003 19:58:42 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19bqjd-0008Jt-IC for emacs-devel@gnu.org; Sun, 13 Jul 2003 19:58:29 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19bqjV-00081F-H6 for emacs-devel@gnu.org; Sun, 13 Jul 2003 19:58:22 -0400 Original-Received: from pop016pub.verizon.net ([206.46.170.173] helo=pop016.verizon.net) by monty-python.gnu.org with esmtp (Exim 4.20) id 19bqjS-0007sO-CN; Sun, 13 Jul 2003 19:58:18 -0400 Original-Received: from WINSTEINGOLDLAP ([151.199.17.220]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030713235817.UTQL3199.pop016.verizon.net@WINSTEINGOLDLAP>; Sun, 13 Jul 2003 18:58:17 -0500 Original-To: "Stefan Monnier" X-Attribution: Sam X-Disclaimer: You should not expect anyone to agree with me. Mail-Copies-To: never In-Reply-To: <200307132306.h6DN6Wpq004158@rum.cs.yale.edu> Original-Lines: 56 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [151.199.17.220] at Sun, 13 Jul 2003 18:58:15 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15587 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15587 > * In message <200307132306.h6DN6Wpq004158@rum.cs.yale.edu> > * On the subject of "Re: emacs floating point error during dump? " > * Sent on Sun, 13 Jul 2003 19:06:31 -0400 > * Honorable "Stefan Monnier" writes: > > - modifying an elisp macro will not automatically force a rebuild of > all the .el files that make use of it. 1. all *.elc should depend on the dumped few files like subr.el. 2. if a foo.el uses a macro defined in bar.el, then it should (require 'bar) and a simple grep+sed cen generate the dependency. I did something similar for a Commol Lisp package 5 years ago (before switching to defsystem), it worked just fine. > - changing from `make' to `make CFLAGS=-DENABLE_CHECKING' does not > force recompilation of the .o files. This is not a dependency issue. If you type a make argument, you can as well type "make clean", right? > - modifying `Makefile.in' will correctly cause rebuilding of > `Makefile' but will fail to reconstruct the targets that the > Makefile describes. I am afraid you lost me here. Do you mean that every target should depend on the Makefile? If yes, I am sure you can easily add Makefile to each target line. > - upgrading libc will not automatically cause `configure' to be rerun. this should not be too hard to fix, I guess: config.status: ${srcdir}/configure /lib/libc.a ./config.status --recheck [of course the location and the name of libc will have to be somehow determined...] but how often do you upgrade libc? > - deinstalling libpng does not automatically cause `configure' to be > rerun. again, this can probably be fixed... The bottom line on these last two items is that host system dependencies are probably less important than the Emacs interdependencies because the host system can be presumed to be more stable than the Emacs development tree. -- Sam Steingold (http://www.podval.org/~sds) running w2k If you think big enough, you'll never have to do it.