From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Bootstrap deleted DOC-nnn file Date: Sat, 11 May 2013 12:09:57 +0900 Message-ID: <87vc6qdxfe.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83vc6rb31c.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1368241809 10781 80.91.229.3 (11 May 2013 03:10:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 May 2013 03:10:09 +0000 (UTC) Cc: Eli Zaretskii , rms@gnu.org, "emacs-devel@gnu.org Development" To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 11 05:10:08 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ub0CE-0008ID-7O for ged-emacs-devel@m.gmane.org; Sat, 11 May 2013 05:10:06 +0200 Original-Received: from localhost ([::1]:42125 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ub0CD-000306-NN for ged-emacs-devel@m.gmane.org; Fri, 10 May 2013 23:10:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ub0CA-0002xX-8h for emacs-devel@gnu.org; Fri, 10 May 2013 23:10:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ub0C9-0000hj-69 for emacs-devel@gnu.org; Fri, 10 May 2013 23:10:02 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:52848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ub0C6-0000h2-Tj; Fri, 10 May 2013 23:09:59 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 713EC970930; Sat, 11 May 2013 12:09:57 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3671A1A4F35; Sat, 11 May 2013 12:09:57 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159494 Archived-At: chad writes: > On 10 May 2013, at 15:08, Richard Stallman wrote: > > However, it is a bad thing to delete the old executables too. > > It is sometimes useful to compare behavior of the new version > > with the old version. There is no need to delete them, > > so let the user decide. > [The ns port] uses a relocatable install, so the entirety of emacs > lives inside a single emacs-only directory tree (Emacs.app). This > makes multiple versions very easy to manage, and I keep at least > two independent emacsen around at all times. It's saved me more > than once. Richard, I agree with you that it would be nice to have access to the DOC file, but I think that might best be served by tweaking the DOC- file-finding routine to look for its DOC first, then a DOC of a later build, then a DOC of the same version, and finally any DOC at all. Of course due to the way DOC files are indexed you still might lose, but it's worth a try. Fuzz the index a bit and search "near" the baked-in index for the entry when you don't have an exact match. Another fallback would be to do a find-function if the DOC file doesn't exist or you can't find the docstring in the DOC file. A third is to embed the DOC file in the executable, with an option to keep it separate for users who need a slimmer executable (with modern OS technology, are there any? :) For the executable, I think you are in a small minority that isn't best served by Chad's solution of a relocatable install. True, it involves extra effort and time to "make install", but you're already doing a bootstrap. In heavy hack-build-test cycles, one doesn't do a "make clean" even, let alone a "make bootstrap-clean". No problem there, it's only when you have an expensive "make bootstrap" that you want to precede it with "make install". I don't know if the content-finding code that is used by the ns build is generalized to all Emacs builds, but if it is you can get relocatable builds for free. If not, it's not that hard (and Mike Sperber did it for XEmacs, I imagine he'd be willing to discuss the fine points that caused him pain). A final point: In the case of "the old version", I'm pretty sure you mean "the last version I built", which probably will still work. Most of us, however, have substantial churn in our libraries due to distro updates, and my experience is that old executables typically have a lifetime of about 1-3 months (normally due to a security patch to libpng, but who's counting? ;-) After that the executable won't load anyway, unless statically linked. Almost nobody does that anymore. So cleaning up old versions is a harmless convenience for most developers. (I suppose you could do a "keep last N versions" the way the traditional Emacs backup-versioning code does.)